トーク

みなさんサーバーレスってますか？PHPerでもサーバーレスってますか？
どうやら世の中サーバーレスだったりマイクロサービスだったりがモダンなようです
AWSは使っていても、構成は結局LAMPどまり…というぼくが、次の新規案件にサーバーレスを採用しようと決めました
一足遅くなりましたが、このビッグウェーブに乗ろうとしたぼくの過程をお話ししたいです

ためしに、このトーク用に #サーバーレス で動くモノを作ってみたいと思います

最近ではフロントエンドをJavaScript(typescript)を使用して開発するケースが増えていると思います。
また、最近ではnodejsを使ってのSSRなSPAアプリだけでなく、GatsbyやNext.jsのようなReactベースの静的サイトジェネレータも注目されています。

このセッションでは、2年ほど前にSlim3で作った簡単なPodCast配信用WebアプリのReact/Next.jsでの作り直し作業を通して、React+Next.js+SSGで静的なサイトとして構築する際の構成やメリットなどを解説したいと思います。

いわゆる「大規模」と言われるウェブサービスで、SEOを考えるときに直面するのが、「クロールバジェット」と呼ばれている、クロール割り当ての最適化です。
婚活パーティーのポータルサイトであるオミカレでは、最大で4万件以上の婚活パーティーの情報と、それを検索するための都道府県・市区町村・ジャンルといった多種多様なリストが存在し、「ページ」数は膨大なものとなっています。
その膨大な中から「Googlebotに見てほしいページ」にどうやって効率よく誘導するか？はとても大きな課題です。
そこで、2019年6月に行ったオミカレのフルリニューアル以降、直面したクロールバジェットにおける問題や対処法について紹介します。

主な内容

• 立ちはだかるリニューアル前のURL
• 想定通りにならないcanonical
• 第一回リダイレクト祭り
• 居座るはるか昔の日付
• 一筋縄では行かないrobots.txt
• 検索とパラメーターとインデックスとランディング
• 終わらない内部リンクの検証
• 第二回リダイレクト祭り
• これまでの教訓

PHP界隈でもドメイン駆動設計の話題が盛んな昨今ですが、正しい設計のためには前工程としての要件分析が不可欠です。詳細な設計に入る前にプロダクトオーナーが読み解ける形式の文書で合意を取っておけば、最小のコストで「本当に必要なもの」を作るための足場となります。また、ドメインエキスパートを設計の深いところまで連れて行くための道標も手に入るでしょう。

このセッションでは、システムとユーザーの相互作用をユースケースシナリオとして表現し、そこからオブジェクト指向らしいクラス設計を導く手順を紹介します。設計スコープと目的レベルについて理解し、簡単なフォーマットさえ覚えれば、誰でも明日からユースケースシナリオを活用できるようになります。

一昨年、昨年とWebアクセシビリティの前提や概念についてたくさんお話してきました。
そろそろじゃあどうやって実装するんだという意見を聞いたり聞かなかったり。

PHPerでも一度は言われたことがある（？）「簡単でいいのでお問い合わせフォームを作って欲しいのですが。」「ここマウスカーソルがあたったときに説明が出したいんですが。」「ここにタブを用意して切り替えられるようにしたいです。」
ときにはJavaScriptか…と思いながら実装をしているかと思いますが、きちんと伝えるべきユーザーに伝えられていますか？
これまでのトークから一歩踏み出して具体的なWebアクセシビリティを意識した実装についてお話したいと思います。

本トークでは下記についてお話をします。
・今からでも遅くない！Webアクセシビリティ入門
・Webアクセシビリティを意識した実装とは
・WAI-ARIAについて
・WAI-ARIAを用いた実装事例紹介

エンジニア向けイベントのスポンサー担当をここ数年やっています。
会社としてはもともとそんなに積極的にスポンサー活動をしていたわけではないので、どういったことをきっかけにするようになったかの背景を始め
・スポンサーするにあたって予算とかどうしている？
・効果測定は？
・実務面では何している？
について話します。
このトークをきっかけに、より多くの会社様がエンジニア向けイベントのスポンサーになってもらえればと思います。
もっともそれ以前に、スポンサー担当していると、自社のロゴがイベントサイトに掲載されたり、会場でロゴがあったりするだけでイベント参加が一段と楽しくなるので、そういう楽しさを是非共有したいです。

PHP 7.4 で追加された FFI を通じて、 Linux の FUSE を利用することができます。
つまり、今や我々は PHP でファイルシステムを作ることができるのです。
たとえば WordPress ファイルシステムを作ってマウントすることで、grep や sed を通じて DB 内の記事データを編集するような誰得な操作も可能となります。
このセッションではそんな FFI による大道芸、PHP によるシステムプログラミングの実例とそこで使われている技術について簡単にお話します。

AWS,GCPなど様々なクラウドリソースのコード管理を実現するTerraform。
小規模なインフラ構成であれば単一レポジトリにディレクトリを分けずに配置して、シュッとお手軽に利用できます。
しかし、大規模な構成になってくると、途端に管理が面倒になり、ベストプラクティスも存在しない世界になります。。
このトークでは、Terraformのレポジトリ、ディレクトリ構成について、これまでの苦闘した軌跡と、現状のベストだと思う構成、将来的にどうあると良いと考えているか？について話します！
トーク後にはぜひみなさんとディスカッションしていきたいです〜

2021年のPHPはPHPStanやPhan、Psalmを用いる事で型検査や不要なコードの検出が可能です。
新規のプロジェクトでは、初期から静的解析ライブラリを導入することにより実行時エラーをデプロイ前に検出することができますが、古くからあるプロジェクトでは、導入しても十分に静的解析の力を発揮することができない場合があります。
古くからあるプロジェクトに静的解析ライブラリを導入するために、何が静的解析の障害となっているか調査しました。
計画的にレガシーコードのリファクタリングを行なうために行なったコードの解析手法についてお話しします。

PHPでは配列の初期化処理がopcode列にコンパイルされて実行されるため、巨大配列の初期化は実行時にコストがかかっていました。ところが、PHP 7からは定数だけで構成された配列リテラル（＝定数配列）をコンパイル時に生成して利用するように変わっています。さらに定数配列はOPcacheのキャッシュ対象になっているため、キャッシュヒットすれば巨大な定数配列を生成コストなしで使えるようになっています。本トークでは技術的背景を簡単に説明した上で、定数配列とKVS（APCu・memcached・Redis）で同じ機能を実現した場合の性能比較を行います。

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

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

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

• セッションの仕組み
• ウェブアプリケーションフレームワークにおいて利用されているセッションの例
• セッションが本番アプリのアーキテクチャに与える影響

普段みなさんは PHP を動作させるミドルウェアは何を使用していますか。よく一般的に使われるのは Apache の mod_php や PHP に備わっている php-fpm をベースとし nginx からリバースプロキシさせる方法だと思います。
私の所属している株式会社トラーナでは物流をベースとしたシステムが必要になり、どうしても一つあたりのレスポンスが大きいデータを取り扱う必要があります。元々弊社では php-fpm を使用していましたが、パフォーマンスが著しく遅く、そこで swoole と laravel-swoole を導入し、8倍もの高速化を行いました。
そこで、本セッションでは導入する際にハマったポイントや、導入する点でのメリット及びデメリット、そしてどのように導入していくか、最後にどのようにプロダクション環境へと昇華させるかというトークをさせていただければと思います。

「エラーと向き合う」ことは、プログラムの品質を極める上で最重要な要素の一つです。
では、PHPが持つ「エラー」とは、いったい何を意味しているのでしょうか？
面白いのは「時代の流れに応じて変わってきている」点であり、またそれがphperを悩ませるのも点でもあります。
「エラーとは何なのか」、PHP8が登場した今の時代に改めておさらいしてみませんか？

PHPにはたくさんの「異常」を知らせる仕組みがあります。
まず初めに「エラーレベル」があり、PHP5で「例外」が導入されました。次にPHP7で当初"EngineException"と称された「Error」が登場します。
そしてPHP8では、「Error」の適用範囲が増えたり、あるいは(時には処理実行の中断を伴う)エラーレベルの引き上げが実施されました。

最も顕著なのは、組み込み関数でも引数が宣言された型に合致しない場合にTypeErrorを発生させるようになった点でしょうか。
もしくは、未定義変数を利用した場合のエラーレベルがNoticeからWarningに引き上げられた点だ、と言う人もいるかも知れません。
どちらも昨今のPHPが”より真面目に”プログラミングのエラーに向き合うようになりつつある態度を感じます。

本セッションでは、PHP7時代を振り返って「Throwable/Error/Exception」を整理するとともに、エラー関連の挙動に注目しながらPHP8の「堅牢さ」についても考えてみたいと思います。

PHPerKaigi2019でお話しした内容（ https://fortee.jp/phperkaigi-2019/proposal/61b5c154-7b53-4d78-820a-cf328f6d3360 ）を
PHP8の環境で、再度検証してみた話をお伝えします
さらに、Swooleを用いたフレームワークでもっともGitHubの更新頻度が高い
Hyperfを加えて、４種類のフレームワークをくらべてみます
そもそも、PHP8のJITはどれだけSwooleに有利に働くのでしょうか？
PHP8の環境における、No.1 Swooleフレームワークはどれだ！

Web サービスに会員登録したユーザーの真正性を担保する方法の一つとして、登録したメールアドレスに認証用のメールを送信するというものがあります。
Laravel では User モデルでメール認証用のインターフェースを実装し、本人認証が必要なルートをミドルウェアで保護することで簡単にこの機能を実現できます。
しかしその反面、認証機能の具体的な仕組みはブラックボックスとなっており、少し複雑な要件が追加されると拡張が難しくなってきます。

このセッションでは Laravel のメール認証の機能を紹介するとともに、内部実装を掘り下げることでその仕組みを理解し、フレームワークの推奨する方法に囚われずにメール認証を実装する例を紹介します。

ボードゲーム、お好きですか？

僕が好きなボードゲームのひとつに『モザイク』というゲームがあります。
趣味が高じて『モザイク』のライブラリや、それを用いた対戦Webアプリや機械学習させたAIまで作ってしまったほどです。
(ただし本人の腕前はサッパリ)

ところで、ゲームの盤面を管理するための「ビットボード」という手法をご存じでしょうか？
2進数を用いて盤面を表現し、ビット演算を用いて盤面を計算します。
この手法はとても高速で、将棋やリバーシといったゲームの機械学習分野でも広く使われています。

本トークでは『モザイク』をビットボードで実装した経験を踏まえ、以下の内容をお話しします。
(セッション内で扱うコードはすべてPHPです)

• ビットボードとは
• ビットボードって本当に速いの？ 比べてみた
• 『モザイク』をビットボードで表現するには
• 盤面の計算

以下の内容は時間があればお話しします。

• セッション内で用いるビット演算の説明
• 64bitより大きい盤面を扱う方法

以下の内容は扱いません。

• リバーシや将棋のビットボードについて (『モザイク』しか実装したことがないため)
• 機械学習やAIについて (そちら方面は素人であるため)

Google製のRPCフレームワーク、gRPC。
"ユニバーサル"を謳っているものの、ブラウザ上でgRPCクライアントを実装することはできず、またPHPによるgRPCサーバの実装は一般的に困難です。
PHPによるサーバアプリケーションとブラウザ上で動くWebアプリケーションを主な生業とするPHPerとしては手が出にくくなっています。

gRPC-Web（ https://github.com/grpc/grpc-web ）は主にブラウザとサーバの間でgRPCに準じた通信を可能にするための、JavaScriptによるクライアントライブラリおよびそのプロトコルです。
gRPCに比べていくつかの制限はありますが、メリットの一部を享受することができます。

本トークではgRPC-Webの概要やgRPC-Webを用いたアプリケーション開発のメリット・実装例をご紹介し、PHPによるサーバ側の実装に挑戦した結果をお話しします。

お話ししたいこと

• gRPCの概要
• gRPC-Webの概要と現状
• クライアントコードの自動生成
• デプロイ/インフラ構成
• アプリケーション実装例（C#実装を予定）
• PHPでどこまでいけるのか（これからやります）

お話ししないこと

• 本番運用の事例
• パフォーマンスチューニング

速いは正義、アプリケーションは速くあるべきです。

PHPWebアプリケーションを構成する要素として、
パフォーマンスを向上させるポイントはどこにあるのでしょうか。

今回はPHPWebアプリケーションを速くするポイントを
PHPに限らず幅広い視点で見直してみようと思います。

OS、Webサーバー、PHP、RDBMS等の見直すべき要素に関して触れ、
愚直に改善を行うべき場所を再考し、
堅実にパフォーマンスを改善する方法をお話しようと思います。

■想定する聴講者
　- PHPWebアプリケーションのパフォーマンスに興味がある方
　- PHPのインフラを整備するエンジニア
　- PHPでISUCONに挑戦する方

■お話しないこと
　- パフォーマンス以外の話
　- アプリケーションコードによる改善
　- 劇的なパフォーマンス改善策

「アーキテクチャテスト」って何？と思われたあなた！

アーキテクチャテストとは一言でいうと、

• Layered Architecture や Clean Architecture のような設計パターンで実装された、アプリケーションを構成するクラスの依存関係を自動テストとして表現し、テストすること
• 依存関係の他にも、そのアプリケーション固有の実装ルールをコード化して、自動テストすること

です。

私の普段の開発業務でのメイン言語は Java ですが、「アーキテクチャ」は開発言語によらず存在する重要なテーマです。

この発表では、Java での実際のプロダクト開発で実践しているアーキテクチャテストの知見をもとに、アーキテクチャテストが有用な理由、つまり

• アーキテクチャ設計という営みの課題
• アーキテクチャの正体とその問題点

に迫りながら、PHP の文脈で PHP のライブラリを用いて、PHPer として「アーキテクチャテスト」に入門してみます。

＜参考＞アーキテクチャテストに関する過去の登壇資料などのリンク集
https://gist.github.com/kawanamiyuu/f63fe97136bb189f53346245fdfac808

皆さんテスト書いてますか？モックしてますか？
テストを書くときにDBや外部サービスをモックしていると思いますが、順番にデータベースへの書き込みを行っていくような手続き的な処理をテストするとなると、テストコードがモックの差し込みだらけになってしまい、とても見づらくなってしまいます。
また、モックの差し込みを書けば書くほど、これって本当にテストになっているのかと疑問になってきませんか？これを解決するために弊社では、あえてDBにつないでテストするということをしているので紹介します。