トーク

ステートレスな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につないでテストするということをしているので紹介します。

• とある企業でDBAを務めていますが、お手製の監視スクリプトをytkitというスクリプト群としてオープンソースで公開しています
  • https://github.com/yoku0825/ytkit
  • 一番使っているのが監視スクリプトである yt-healthcheck というやつです
• コイツはまあ、Perlで書かれてるんですが、これを見ながら「本職のDBAはこんなこと考えながらMySQLの監視してるんだな」という紹介です
  • いいじゃないですか、変数名の頭に$がつくPで始まるもの同士仲良くしましょう！
  • なお、私のPerlはへたっぴです。監視用のSQLだけは自信があります。

PHPerの皆さんは、日々Webアプリケーションを開発している中で、フレームワークのコードと自分たちのコードを区別できていますか？
自分たちのアプリケーションにとって重要な、業務知識をモデリングして書いたコードは、「いまのフレームワーク」と切り離して動かすことができるでしょうか？

フレームワークのバージョンアップ、あるいはフレームワークの開発終了によって自分たちのアプリケーションの命運が左右されることがないように、フレームワークへの依存を取り除き、大事なコードの可搬性を高めましょう。
ごく一般的な小さなWebアプリケーションを題材に大事なコードを守りつつLaravelからSymfonyにフレームワーク変更する様子を実演しながら、考え方とテクニックについてご紹介します。

PHPで画像に縦書きテキストを描画する話です。
横書きテキストしか描画できないImageMagickと、ICU (Intl) を使って実現します。
発表では以下の内容を踏まえて縦書きテキストを画像に描画する方法とその要素技術についてお話しします。

• 縦書きテキストとは何か
• テキストを構成する文字について
• 文字を描画するためのフォントファイルについて
• フォントファイルを扱う時に便利なttxというツールについて
• PHPから使えるImageMagickについて
• PHPから使えるICUについて
• 文字列を折り返すということについて

6年続くWebサービスをリプレイスすることになりました。
あなたならまず最初に何から手を付けますか？

このトークでは、弊社（コネヒト）が運営するママ向けNo.1アプリである「ママリ」のシステムの一部（CakePHP2.x / PHP7）をリプレイスしている状況を共有したいと思います。
長年に渡って機能改修が繰り返され、複雑なドメインを有するサービスは単純にフレームワークを新しくしたり、あるいはLaravelなど別のフレームワークに載せ替えるだけでは解決できない問題がたくさんあります。

様々な工夫を凝らし、今回の基本戦略である「無駄な物をなるべく作らない」という方針でどうやってリプレイスを進めているのか、具体的なプラクティスを交えながらご紹介します。

厳選したPHP8ネタを、カンファレンスでも引っ張りだこの人気プログラミング講師・なるせ先生に出題。
PHPのみならず、さまざまな知識の引き出しを持つなるせ先生でさえ知らなかったものを「PHP学」に認定する。
なるせ先生が「知らなかった！」と申告したら出題側の勝利。
知っていたネタはなるせ先生が”生授業”で自ら解説する。
まさになるせ先生が貯蔵する知識量との大勝負！はたしてどんな驚きの情報が飛び出すか！？

PHP製オープンソースCMS「Drupal」をご存知でしょうか。
OSSとして公開されて今年で20年目を迎える老舗ソフトウェアですが、オブジェクト指向やSymfonyの採用、Composerの導入、ヘッドレスCMSへの対応など、多くの技術トレンドを取り入れながら進化し続けています。
日本ではあまり知られていないですが、世界に目を向けるとあんな企業やこんな組織が、色んなところでDrupalが活用されています。
Drupalを触ったことがない、聞いたことがないPHPerの方々に向けて、Drupalで何ができるのか、Drupalの魅力についてご紹介します。

人は言います——モジュールを疎結合にせよ、と。
人は言います——具象ではなく抽象に依存して実装せよ、と。

ソフトウェア設計におけるベストプラクティスは異口同音に関心の分離の重要性を説きます。SOLID原則の「D」ことThe Dependency Inversion Principle / 依存性逆転の原則を実装するための道具立てとしてDIコンテナ、あるいはIoCコンテナと呼ばれる仕組みが利用されることがあります。

「PHP DI」などで検索すると、さまざまな説明が読めることでしょう。……御託はわかった。しかし昔の私には問題意識も活用方法も理解できず時間は過ぎ去っていきました。フレームワーク嫌いの私も数年も経験を積み、いくつかのフレームワークに触れてそれぞれの長短がわかってくると「Laravelのこれだけ使いたい」とか「CakePHPのここだけ羨ましい」などと考えはじめるものです。

このトークではPHP-DIに触発された簡易的なDIコンテナの実装方法を紹介し、PSR-18のような外部と通信するインターフェイスを分離しオブジェクトの生成をDIコンテナのオートワイヤリングに任せることで、どのように実装を簡潔にできるかを説明します。発表内容は実装にフォーカスしており、設計原則やソフトウェアアーキテクチャについては言及しません。

今回の発表では以下のコードの実装時に得られた知見を含みます。

• 特定のフレームワークに依存せずPHP-DIを用いてオブジェクト生成とメソッドのディスパッチを行なったWebアプリケーション
  https://github.com/phppg/phperkaigi-golf
• リフレクションを用いてメソッドを動的ディスパッチするライブラリ
  https://github.com/bag2php/meta

トラブルの耐えない決済システムをPHP×Laravelフレームワークでリプレイスするにあたって、どのような課題に対して、どうやって改善したかをお話します。

前半20分は、リプレイス後の決済システムのしくみについて、後半20分は、20万レコード更新を同期処理で実現したことについて、弊社DBAのyoku0825さんと感想戦をします。

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

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

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

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

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

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

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

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