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

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

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

です。

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

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

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

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

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

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

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

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

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

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

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

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でどこまでいけるのか（これからやります）

お話ししないこと

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PHPに限らずエンジニアとして日々技術情報をインプットすることは重要です。
技術情報はただインプットするだけでなく議論を通して様々な角度から捉え直すことで、より深い知識を得ることができます。
そのような深い技術知識をインプットするために、弊社ではPHP関連の最新情報について語り合うイベント「PHPTechCafe」を毎月開催しています。
イベント運営には様々な試行錯誤がありましたが、PHPerKaigiをはじめとしたコミュニティの取り組みを参考に自社イベントを継続した結果、参加者100人以上、著名なPHPerにも参加して頂くなど、イベントの成長と拡大を実感できています。
私自身、イベント内で参加者同士の議論に参加できるように海外のニュース記事やホットな技術情報を積極的に収集していくうちにPHPエンジニアとしての成長も感じられるようになりました。
この発表では、自社イベントの運営スタッフを経験していくうちにイベントの成長とともに自分自身もPHPエンジニアとして成長を実感できた経験とその取り組み事例をお話します。

普段DNSについてあまり気にせずに使えるため空気のような存在になりつつありますが、
DNSの事件や仕組みを見ると、インターネットの根幹を支える技術の一つだとわかります。

ここでは次の3つからDNSを理解し、DNSが持つ力を感じてもらいたいと思います。
・DNSの仕組み
・ドメインハイジャック事件と対応策
・DNSとプライバシー

ドメインハイジャックは、実際の事件の紹介、仕組み、その対策としての改竄検知についてお話します。
プライバシーは、DNS Proxyサーバを作成して自宅で運用した（子供のYoutube時間をDNSで制限した）話から、DNSサーバから何が見えるのか、プライバシーはどうなるのか、そこからOblivious DNS over HTTPS(ODoH)とは何かをお話します。

30年以上前の仕組みが今もなお同じように動いていて、私たちのインターネットを支えています。
普段の開発では知らなくても動いているDNSですが、DNSキャッシュや権威サーバのツリー構成など知っておくとトラブルシューティングやサイト移転時に役立ったりします。

Nuxt.js は Vue.js をベースにした SPA や SSR が比較的簡単に実現できるフレームワークです。
Laravel の Blade のようなテンプレートシステムで構築していたフロントエンドを Nuxt.js のようなフレームワークに移行する際、あるページは Blade を、また別のページは Nuxt.js を使って構築するというように両者が共存する状況が起こりえます。

このような少し込み入ったアーキテクチャのシステムにおいて、 A/B テストの基盤を自前で構築する機会がありました。
Laravel と Nuxt.js の両方で同様に機能させるための設計、ユーザーの振り分けロジックの実装、 A/B テストの結果の集計方法といった知見をこのセッションで共有できればと思います。

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

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

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

あなたはDIというワードを耳にしたことがあるでしょうか？
直訳すると「依存性の注入」という言葉で言い表されるDIですが、この概念自体は新しいものではありません。

Javaにおける開発では一般的であり、PHPのフレームワークであるLaravelではサービスコンテナと呼称される仕組みが提供されていたりもします。
しかし、DIを雰囲気で使っている人もいるかもしれませんし、そもそも使った経験がない人もいるかもしれません。

・「知らないなんて、今更言えない。」
・「触ってみたけど、よく分からなかった。」
・「そもそも、依存を言葉で説明できないかも。」

このセッションでは、不安を抱えながらDIのことを見つめている方に向けた掘り下げをしていきたいと思います。
資料の構成はこれからですが、実際のコードを交えつつの解説をしていくつもりです。特定のフレームワークに限定した内容にはしません。

プログラマの三大美徳とは次の通り（Wikipedia より引用）。

怠惰（Laziness）
短気（Impatence）
傲慢（Hubis）

デプロイ作業は単純作業が入り込みやすいです。もし「怠惰」なプログラマだったら単純な繰り返し作業なんて嫌なはずです。
デプロイ作業は時間がかかります。もし「短気」なプログラマだったら長い待ち時間に我慢できないはずです。
デプロイ作業はミスが許されません。もし「傲慢」なプログラマだったら自動化してミスなどしないはずです。

私の所属する会社でもかつては、かつてはほぼ手動でgitコマンドを順番に打って、タイミングを見計らい migrate し、長い待ち時間に甘んじたこともありました。
しかし徐々にフローは自動化され、完璧とは言えないまでも三大美徳を徐々に実現してきました。
PHPerであろうと他の言語のプログラマであろうと避けられないデプロイフローの話をお届けします。

はじめてのアクセス制御の導入でCasbinというライブラリを使ってみたらすごくよかったので紹介します。

Casbinを用いたロールベースのアクセス制御の導入を例に挙げて、
権限モデルの種類やCasbin、CasbinのLaravel向けパッケージであるlaravel-authzなどについて話します。

元々パッケージとして開発していたソフトウェアですが、リライトせずSaaS化をしたという話です。

qiitaで途中まで書いた話です。
https://qiita.com/Rei_okawara/private/ec0dfe9bf552f7d78101

みなさん N+1 問題ってご存知ですか？DB への接続をループ分で N 回実行し、+1 はカウントで全件数を取ってきたりすることを総称して N+1 問題というかと思います。他にもループ分で N 回実行しているコードだけのものも総称して N+1 問題と言ったりしますね。言葉の真意は神のみぞ知るですが、概ねこういった理解の方が多いのではないでしょうか。もちろん N+1 は DB に限らず外部リソースへの接続も同様と理解すべきです。外部リソースといえばキャッシュ用の Redis もそうですし、全文検索エンジンの Elasticsearch も同様です。1 回の接続であれば目を瞑ることもできますが、ウェブアプリケーションとして稼働している場合、そういうわけにもいきません。そして、N+1 問題はパフォーマンスチューニングにおいて重要なファクターの一つにあげられることも多いかと思いますが、具体的な改善方法は中々調べても出てきません。そこで、本トークでは N+1 問題をそもそも生み出さない方法はどうするのか、既存のアプリケーションから N+1 問題を改善するためにはどうしたらいいのか、といった今後あなたが開発をしていく上での一つの引き出しになれるようなトークを私の今までの経験を交えてできればと思います。

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

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

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

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

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

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

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

おしながき

• Rectorってなに？
• どういう仕組で動いてるの？
• 具体的にどうやって使われてるの？ 〜CakePHP4の アップグレードコマンドを例に〜
• 独自ルールを作ってみる

普段の開発において、OSSのライブラリやフレームワークの利用は欠かせません。
そこで「これはどう動くんだろう」「何でこんな動きをするんだ」と思った時にできること・・・公式のドキュメントを読んで見る、インターネットに公開されているブログ等の情報を探してみる。
そして「ソースコードを読んで見る」、「マージまでの経緯を読んで見る」ことです！
ソースコードを読むためには、多少ボリュームのあるソフトウェアからでも「目的の場所を手早く見つけてみる」のが重要です。
また、OSSならではの利点として、コードだけでなく「そこに至るまでにどんな議論があったか」という情報にもアクセスすることができます。ここでもまた、多少のコツを掴んでおくと便利です。

今まで「フレームワークのコードを読んでみるのは苦手だ」「ググって欲しい情報に近い解説やQ&Aが出てこなかったら諦めちゃう」という日々を過ごしていたあなた！
私の周りにも、「ライブラリのコードを読むのは怖い」「面倒くさそう、億劫だ」という人がチラホラいるものと感じます。
もし「ドキュメント探すよりコード読んだ方が早いわ」という選択肢を手に入れられたら、きっと楽しいことになりますよ・・！

明日からは「もっとライブラリと仲良くなれるぞ♡」な日々を歩んでいきませんか？
本セッションが、そのための勇気をもたらす最初の一歩となれればと思います！