トーク

「より良くPhpStormを使うために、コーディング規約やテスト実行の設定をプロジェクトやチームで共通化しよう」

.idea/ ディレクトリを.gitignoreで無視するように設定しているレポジトリをよく見かけます。
もし”慣習的に”そうしているのであれば、勿体ないかも知れません！

普段の開発にPhpStormやInteliJ IDEAファミリーを利用している方も多いのではないかと思います。
高機能でありながら、「少しだけ」使う分にも充分に威力を発揮することには、ユーザーの皆さんも同意されるのではないかと思います。
他方で、「設定しなければいけない項目」も少なくないのも事実です。

Inspectionの設定、Interpreterの設定、テスト実行の設定・・・
これらを「PJメンバー全員で同期する」ことができれば、一気に効率が良くなります。
「生産効率」の水準が揃う、という手段となります。

そのための手段が「.ideaを共有する」なのです！！

どのように使えば良いのでしょうか？
また、それによってどこまで実現できるのでしょうか？

本トークを通じて紹介します！

最近の PHP コードは意外と型の恩恵が得られます。
PHP 7.0 でのスカラ型宣言、7.1 での nullable、7.4 でのプロパティ型宣言、 8.0 での Union や明示的 mixed の導入といった言語自体の機能追加もあるのですが、psalm や phpstan といった静的解析ツールを利用することで、静的型検査や mixed の排除、Type Erasure な Generics の利用といったことさえできます。
このトークではそんな最近の PHP の型事情、ツールについてのお話や、実際に静的解析ツールを最高レベルで利用し型をガチガチにしながら PHP コードを書く際の注意点についてお話します。

「プロダクト開発が、メンバーの技術力を高めるのか」「メンバーの技術力向上が、プロダクトの品質や可能性を高めるのか」
皆さんは、この「鶏が先かと卵が先か」に似た構造を持つ問題についてどのような考えをお持ちでしょうか？

本セッションは、自分自身の取り組んでいることを紹介した上で、
オーディエンスの皆さんからの視点や経験を織り交ぜたフィードバックと議論を集め、『共有知』を生み出す試みとしたいと考えています。
(折角のオンライン＆録画発表なので！)

この課題を選んだ背景

プロダクト開発や(Web)サービスの提供を行う会社において、
Webエンジニアに求められる主要な成果は「プロダクトを良くする」ことだと思います。
プロダクトをよく出来るエンジニアとは、どういう存在でしょうか？
実は、「プロダクトをよく出来るエンジニア」になるには「プロダクトを開発する以上の技量」が要求されるのではないでしょうか。

ここには大きな矛盾があると考えています。
「プロダクトを良くし続けるには、プロダクトに必要なレベルの技量では足りない」という矛盾です。
これについて、自分自身が、所属先の企業でのロールが変化したのをきっかけに取り組むようになりました。
組織の姿が「プロダクトを作れる」を超えた「プロダクトの未来を作れる」ようになるにはどうすればよいか・・？と現在進行系で考えています。

紹介するお話

例えば、以下のような取り組みが「自分なりに考えたこと」でした。

• 「技術力」を定義する
• プロダクトと技術力の関係
• 自分自身が「技術的な成長」を感じた瞬間を構造化して捉える
• その「良いフィードバックの獲得の仕方」を組織的に再現できないか？

こうした話を「議論のネタ」として提供したいと考えています。

※ 以前にタガヤスという技術勉強会でお話した内容の改訂版です。

普段我々が使っているコンピュータシステムというのは、階層的なシステムです。

物理法則から電気回路が作られ、ハードウェアが作られ、ハードウェアの上で動くファームウェアや OS があって、更にその上で動くアプリケーションがあって、アプリケーションの中でも C 言語で書かれた PHP 処理系、更にその上で動く PHP で書かれたスクリプト、というように、何重もの階層化がされています。
土台になるものから高く階層を積み上げていく、というイメージで、階層の上のほうにある技術を高レイヤー、下のほうにある技術を低レイヤーと呼んだりします。

PHP のスクリプトというのは比較的高レイヤーに属するプログラムなわけですが、PHP コードがコンピュータ上で実際にはどう振る舞っているのか、どういう仕組みでできているのか、というのは、当然より低レイヤーの技術で成り立っています。

今回のセッションでは、そんな PHP より低レイヤーの世界へ FFI を通じて PHP スクリプトからアクセスし、PHP 自身から階層をぶち抜いてスクリプトの動作を下の方から覗き見てみるという、少しひねくれたことをやる自作のツール、php-profiler についてお話します。

雑に言うと PHP で ELF と procfs と ZendEngine の内部構造体をパースしつつ FFI で外部プロセスのメモリを読み取り、スクリプトの動作を盗み見るお話です。

私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。
私はこれを「Documentation as Code」と呼んでいます。そして、そのような概念はすでに世の中にあり、時として「Documentation as Code」と呼ばれているようです。
例えばPHPDocなどはソースコード自体の構造とアノテーションをトレースしてドキュメントの自動生成を実現しています。
OpenAPIのように構造化されたデータとして情報を記述することでドキュメントと同時にAPIクライアントやの自動生成が実現できている例もあります。
テストケースに振る舞いを自然言語で併記しながらテストコードを書くことで結果としてテスト仕様や要求仕様のドキュメントで実現するようなアプローチもあります。
私もシステムやコードからドキュメントを生成するようなツールを少なからず作ってきました。
そういった経験から、本発表では、上記のような「Documentation as Code」を実現するツールを独自にモデル化してそれぞれの特性について考えていきます。
そして本発表を通じて皆さんが「Documentation as Code」に興味を持ってもらえればと嬉しいです。

※ PHP カンファレンス 2020 でお話した内容の改訂版です。図表が増えたりデモを失敗しなくなったりします！

PHP は "PHP: Hypertext Preprocessor" の略ですが、この 25 年間で Web は高度化し、複雑化し、それに伴い Web サイトを作るための言語にも、いっそう複雑な機能が要求されるようになってきました。

昨年リリースされた PHP 8 では、満を持して JIT コンパイラ が導入されました。

典型的な PHP アプリケーションは I/O バウンド（DB バウンド）です。JIT はそのような既存のアプリケーションのためというより、これまで PHP が使われてこなかった、使えると思われてもこなかったような、新たな領域への扉を開くものとして、FFI や Preloading との組み合わせを念頭に提案されたものです。

一方、世間の CPU は着実に多コアの時代へと進んできました。今の時代にある程度 CPU を使うアプリケーションを作ることは、JIT を使うだけの話では済まず、何らかの並列処理機構を用いこの多コアの CPU とも向き合う必要があります。

このトークではそんな新時代における PHP を使い、

• FFI でシステムコールを呼び出し外部プロセスのメモリをのぞき見たり
• （非 Web の） GUI ライブラリを利用してデータを可視化したり
• ext-parallel によりプログラムをマルチスレッド動作させたり
• スレッドの動作効率化ため preloading を活用したり
• JIT によりそのようなプログラム全体の動作を高速化したり

といった、一味違った PHP の利用方法への挑戦を紹介するとともに、そこで得られた知見、現状の制限についてお話します。

比較的モダンなフレームワークでは、例外処理や例外発生時の検知・ロギングが仕組まれていますが、PHPでは検知をすり抜けてアプリケーションを終了させる手段が多数存在します。本セッションではPHPのプログラム実行の仕組みから、どのようにすれば検知の網の目をすり抜けることが出来るのかを解説します。この知識を得ることによって、逆にどのようにアプリケーションを作成すれば、比較的安全を担保できるのかが理解できるようになります。

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

• PHPの例外検知機構と検知不能が発生する仕組み
• 最後の悪あがき「register_shutdown_function」の仕組み
• 検知不能状態を検知する方法の提案

バージョン 8 にしてとうとう僕らの PHP にも JIT がやってきました！
が、PHP 8 の JIT は生まれたてで、同じ 8 でも JavaScript の V8 にはまだまだ速度的な面で追いつかない部分があります。
PHP と JavaScript のそれぞれについて、おおむね同等の処理を行うマイクロベンチマークのコードを用い、プロファイルをとりながらああだこうだ言いつつ速さの特性差や PHP の現状の限界、得意な点や不得意な点を探っていきます。

■ 想定する聴講者
典型的な Web アプリケーションは主に I/O バウンドとかそういう現実の話は脇に置いておいて、PHP スクリプトの性能や測定方法が気になる人
今後の PHP の性能の伸びしろに思いを馳せたい人
しょうもないマイクロベンチマークが好きな人

■ お話しないこと
明日から業務に使える役立つ知識

新規サービス開発において、PHPウェブアプリケーションを実際に世界に向けて動作させるためのインフラが必要になります。では、一体どのようにしてインフラを選定したら良いのでしょうか？プログラミングの世界ではDRYやYAGNI等の格言や、アーキテクチャー選定の考え方が浸透していきていますが、インフラにおいては、基準が曖昧です。本セッションでは、ウェブアプリケーション初期構築時のインフラについて実例を紹介しつつ、妥当なインフラを選択するための基準を紹介します。

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

• 選択可能なインフラ環境
• 選定時の基準
• 各環境の利点と欠点

bugs.php.net は PHP の公式 issue トラッカーで、処理系本体と公式バンドル拡張、PECL 拡張をあわせて現在 2000 以上の未解決のバグが登録されています。

古いものでは PHP4 時代のチケットで残っているものもあり、現在サポートされている処理系バージョンにおいてすでに解決済のものや、そもそもバグではないもの、当初は明らかにバグだったとしても 10 年以上その挙動が続いたことで、もはや仕様としてしまった方がよいのではないかと疑われるものなど、色々なチケットがあります。

そんな bugs.php.net の古くからある塩漬けチケットについて、現在サポートされている PHP 7.4 以降でも再現するか、レポート内容が妥当かなどを検証しつつ、修正可能なものについては PR を投げ、修正不可能であったり修正の必要がないものについてはコメントを追加して現在の状況を付記する、という清掃活動に取り組んでみました。

bugs.php.net 自体やチケットの調べ方について紹介しつつ、見つけて面白かったチケット、実際に対応したチケットについてお話します。

サービスが成長し、機能が追加され、データ量が増大してきたある日、サービスが速度面で劣化してきます。そのような状況ではウェブアプリケーションの処理速度を改善するためのチューニングが求められます。しかし、チューニングの経験がない場合、何をすべきか分からず、効果のない改善作業を繰り返してしまいます。本トークでは実際の例を参考にして、どのようにウェブアプリケーションのチューニングを行っていくべきなのかを丁寧に解説します。

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

• アプリケーションが遅いとは？
• 問題の特定方法
• レイテンシーの評価
• チューニングを行う判断基準
• ケーススタディーで学ぶ「実際のチューニング」

Everything Will Be Serverless.
そんな未来は来ないかもしれません。
しかし、私はそんな未来を信じてお話します。

話者は昨年AWS上でFull Serverless SPAの構築を行いました。

今までサーバーを意識したPHPのWebアプリケーションを作成する事が多かったの話者が、
サーバーやRDBMSを使わないFull Serverless なWebアプリケーション構築を通して学んだ知見を共有します。

ServerlessなGo APIとReactのSPA構成を構築して実感した所感もお話できればと思います。

■利用言語、フレームワーク

• Go
• React x TypeScript

■利用AWS リソース

• AWS Lambda
• Amazon DynamoDB
• Amazon S3
• Amazon CloudFront
• Amazon Cognito
• AWS Amplify
• Amazon Athena、Amazon S3 Select
• Step Functions、AWS Batch

■想定する聴講者

• Serverlessに興味がある方
• AWSが好きな方
• 理論はわかるけど実際に構築したことが無い方

■お話する内容

• 実際の構成について
• ServerlessなSPAの開発手法について
• APIとフロントエンドの結合部について
• 開発からリリースまでで実感した所感

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

ではどうすれば良いのか

細かい理論などは気にしない、こうしたら早くなった

結果を貼り付けながら、何をしたのかひたすら話しますが、細かいことは話しません

事前収録であることを生かして、OS、Webサーバー、PHP、RDBMS等の見直すべき要素に関して
情報を詰め込むだけ詰め込むことに挑戦します。

※注釈は付けますので細かな理論はそちらでご確認ください

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

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

ここ数年、フロントエンド技術は目覚ましい進歩を遂げてきました。私たちバックエンドエンジニアもその流れに追随するよう努めていますがなかなかにツライものがあります。なんとかバックエンドでインタラクティブな web アプリケーションが作れないものか…と考えているそこのあなたに朗報です。

Phoenix LiveView
Laravel Livewire
Hotwire

と各言語でバックエンドからインタラクティブなwebアプリケーションを作成するためのライブラリが立て続けにリリースされています。

本 LT では Laravel Livewire を中心に業界の動きを紹介します。

• MySQL InnoDB Clusterという比較的新しい、公式のHAソリューションがあります
  • 今までの(非同期/準同期)レプリケーションに比べると圧倒的にデータの不整合に強い
• 利用開始は非常に簡単、PHP側からは透過的に単なるMySQLのように見えます
  • Group Replicationというmysqld側の技術と、mysqlrouterプロセスが連携して動きます
  • Group Replicationの設定変更はMySQL Shellから操作するのが圧倒的に楽です

しかし流行っているように見えない！
使えるところには使えるソリューションだと思いますので、これを機に勉強してみませんか？

• セットアップの方法
• Group Replicationの仕組みの説明
• mysqlrouterの仕組みの説明

エンジニアにとって、エディタは毎日使うコーディングのお供であり、また、エディタの機能をうまく使いこなすことによって、作業効率は飛躍的に上がります。
しかし、我々はエディタを本当に使いこなせているでしょうか？
普段何気なく使っていると、詳しい人から思いがけない使い方や、便利機能を紹介されたり、
ふとした拍子に知らなかった機能を見つけた経験がある人は多いかと思います。
本セッションでは、メジャーなエディタである VSCode について、存在を知ってさえすれば明日から活用できる（かもしれない）、裏ワザ的な機能や、便利機能を、発表者の独断で紹介します。

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

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

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

M1 Macって魅力的なPCですね
「でも開発環境としてつかうにはどうなんだろう」
と思っている方も多いと思います
M1 Macを用いて、ARM用の開発環境をつくるときにはまった話をしていきます
たとえば、
そもそも基本ライブラリを用意するところ（Homebrew)
PHP8のインストール（PHPBrewを選択）
Swooleの拡張のインストール（PHPBrewの拡張としてインストール）
のハマりポイントをおはなします

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

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

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