トーク

PHPStan を入れると静的なコード解析が出来るのでとてもプロジェクト関わる開発者全員が恩恵を受けられると思います。

ただしある PHP stan は最初から入れている場合は良いのですが、ある程度アプリケーションが大きくなってからだと導入が難しい、もしくは出来たとしても大きなコストを支払わなければ導入出来ない、と考えている方は多いのではないでしょうか。

この LT では、それなりにアプリケーションが大きくなってから PHPStan を導入した際にやった事や辛み、現在の状況などを体験談としてお話しさせて頂きたいと思います。

Webサービスを運営していると、サービスからユーザーにせっかく送ったメールが届かないことがあります。
そのような、何らかの理由で目的のユーザーの元に届かなかったメール＝バウンスメールをどう処理するかは、サービスにとって避けては通れない課題なのではないでしょうか。
また、AWS SESを使っている場合、バウンスメールの数が多すぎるとペナルティがあったりするなど、サービスにとってバウンスメール処理は意外に大事なものだったりします。
このLTでは、そもそもバウンスメールとは何なのか、AWS SESをつかってバウンスメールをサービスにフィードバックするまでを発表します

今まで仕事で携わってきたPHPでの開発において、可読性、保守性が明らかに低かったコードの例を話し、リファクタリングする場合はどうするかなどを説明します。
例えば、メソッドの引数が7個以上ある。変数名が解読不能。if文のネストが７つ以上あるなどです。

新卒エンジニアとして入社して、配属されたのはPHPで書かれた20年もののレガシープロダクト！？
エンジニアとしてプロダクトに関わるのは初めてだし、PHPを書くのも初めて！
一体私、どうなっちゃうの～！？

ということで、今回は新卒エンジニアとしてPHPプロダクトに参画していく中で、苦労した点や、それを乗り越えた方法などをLTでお話できたらなと思います。
僕と同じ新卒エンジニアの方や、PHP入門者の方たちに「あるある、ないない」と楽しんでいただければ幸いです。

皆さんはPHPでの開発でPredefined Interfaces(定義済みInterface)を使っていますでしょうか？PHPにはIteratorやStringableといったシンプルですが便利なInterfaceが用意されており実装することで、独自のクラスをPHPのプリミティブな型と同様に扱うことができます。どうやってPredefined Interfacesを使うのか、どんなメリットがあるのかを解説します。

「OKグーグル」と声を掛けると家の電気やテレビをつけてくれるGoogleアシスタント、みなさんお使いでしょうか。私は毎日大声でGoogleに話しかけています。しかし声を出すのもダルいときってありますよね。そんなときはプログラムからGoogleに話しかければいいんです。

ところでプログラムからGoogleアシスタントにアクセスしようと思うとPythonかGoの事例が多いんですね。Googleアシスタントの裏側はgRPCなのでPythonやGoが多いのは自然っちゃ自然ですけど、PHPもgRPCの正式サポート言語（クライアントのみ）ですから、やればできるはずです。

そんなわけで、本トークではPHPからGoogle Assistant APIを使って「OKグーグル」してみましょう。他の言語より少し大変だったりしますが、PHPだってgRPCで遊べるんです！

誰かが言った。
「データベースの寿命は、アプリケーションよりも長い。」
多くの人が感覚として持っているのではないでしょうか。

この10年間で多くの技術が生まれ、そして変化し、開発の現場も進化してきました。
そんな中、データベースの世界では何十年もRDBMSが活躍しています。
それはなぜでしょうか。
この10年間のRDBMSの変化から開発に必要なことが見えてくるはずです。
そして、そこからこの先の10年を見据えたシステム開発の勘所を紐解きます。
様々な商用データベースに対して、MySQLやPostgreSQLのようなOSSデータベースは如何に追従しているのでしょうか。
そしてクラウドならではの新しい形のデータベースも次々に生まれています。
これらを題材に今、あなたが新しいサービスを作る時、10年戦えるデータベースの作り方を見つけていきましょう。

昨年開催されたISUCON11にて問題（参考実装）のPHPへの移植を担当させていただきました。

最終的なソースコードこそシンプルなWebアプリケーションではありますが、その裏には
・「（私の思う）良い設計」を実現するための意思決定
・「ISUCONの問題」という位置付けに由来する取捨選択
・移植中に遭遇したトラブルとその解決策
といった文脈や葛藤が存在しています。

本発表はそれらを共有することで
・PHPアプリケーションの設計、実装事例として役立ててもらう
・ISUCONの言語移植に興味を持ってもらう
・ISUCON問題移植の「実装や設計の練習をする教材」としての可能性を知ってもらう
ことを目的とします。

なお、以下のテーマは扱いません。
・（移植に利用した）Slim Frameworkの使い方
・ISUCON11の問題解説
・パフォーマンスチューニングに関する知識、技術

php-srcのバグ報告ですが、実は2021年末にbugs.php.netからGitHubへと移行しました。
(厳密に言うと、セキュリティが絡む場合には引き続きbugs.php.netを使用します)

そのため、バグ報告の仕方がすこし違ってきています。
GitHubだからいざ報告となるとしやすくなったのでしょうか？
GitHubで報告されたバグはどのように扱われるのでしょうか？
php-srcほどだとバグは見つからないかもしれませんが、見つけてしまったときにどうしたらよいか考えてみませんか。

個人で PHP 用のプロファイラを作っておりまして、これは FFI を経由して Linux のシステムコールを呼び出し、別プロセスで実行中の PHP 処理系のメモリ内容を覗き見し、内部データを解釈して実行中の PHP スクリプトの情報を盗みとる、という少し変わった PHP スクリプトです。

https://github.com/sj-i/php-profiler

2020 年から半分くらいギャグのつもりで少しずつ開発を続けているものですが、作っているうちに案外実用性が出てきてしまった気がするので、内部実装や利用方法について少しだけご紹介します。

■ 想定する聴講者

• PHP の性能計測についてちょっと変な奴でもいいから手札を増やしたい人
• PHP での低レベル寄りの大道芸が好きな人
• 年に 1 回や 2 回くらいは「PHP で何やってんだよｗｗｗ」という種類の笑いがほしい人

みなさんはコミットメッセージ規約「Conventional Commits」をご存知でしょうか？
「Conventional Commits」を導入すると様々な利点があります。
例えば調査しやすいコミットメッセージをささっと書けるようになったり、ChangeLogを自動生成できるようになったり・・・

そこで本セッションでは、コミットメッセージ規約「Conventional Commits」を導入するとどんなメリットがあるのかを話していきます。

具体的には以下のような内容について話をする予定です。
・コミットメッセージ規約「Conventional Commits」とは何か？
・ツールを使って、Conventional Commitsに沿ったコミットメッセージ作成
・Conventional Commitsに沿ったコミットメッセージを使ったPHPプロジェクトでChangeLogを自動生成

自動テストにおけるテストフィクスチャは、ほぼ全てのソフトウェアにおいて必要になるテクニックです。その中でもデータベースと密接に連携する Web アプリケーションにおいては、データベースにデータを投入し、そのデータをフィクスチャとして利用するテクニックは初期の頃から利用されてきました。

PHPにおいては、 Fabricate という Ruby における factory_bot のような"柔軟な定義構文を用いてフィクスチャを管理する"ためのパッケージや、ここ最近になって CakePHP Fixture Factories という Fabricate に近しいコンセプトのパッケージが登場してきています。

本トークでは、最近登場した CakePHP Fixture Factories の解説を中心に、新たなテストフィクスチャ管理ツールのスタンダードについてお話できればと思います。

カルテット開発部の2人によるLT2本立てでお送りします！
【プライベートな社内パッケージの再利用にsatisを使っている話 by志賀】
みなさんの会社ではプライベートな社内パッケージを再利用する際どうやっていますか？弊社ではSatisというcomposerリポジトリージェネレータを使っています。その事例についてお話しします。
【受託制作会社から自社サービスの会社へ転職して思ったこと by有澤】
自分は「受託制作会社」から「自社サービスの会社」へ転職した身です。
今後、そのパターンに沿って進みたいエンジニアに向けて、感想を共有します。

チーム開発って「スケジュール通りに終わらない」「コミュニケーションが上手く取れない」など、いろんな問題が発生して悩むことが沢山ありますよね。弊社での開発でも同様の悩みを抱えながら、日々開発に奮闘しています。

本トークでは、弊社のプロダクト「カオナビ」での、開発期間約１年の開発プロジェクトにおける、スクラムでのチーム開発の経験談をご紹介します。

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

• どうやって開発を進めていったのか
• 立ちはだかる様々な問題に対してどうやって立ち向かったのか

モデルという言葉から皆さんはどんなものを想像しますか？
我々の日常生活やエンジニアチーム、エンジニア以外のチームとのコミュニケーションでは、
耳に入る言葉にはそれぞれコンテキストが多分に含まれています。
コンテキストを理解せずにそれぞれのチームが微妙に異なった認識で物事を進めると、
どんなことになってしまうのでしょうか？！
コンテキストを正しく理解することは、その時の仕様を満たすシステムを作るだけではなく
うまく活用することでビジネスを加速させるためのコミュニケーション改善や、
複雑な仕組みを解決する力となります。
より良いシステムづくりのためにも是非入門してみましょう！

近年注目を集めるマイクロサービスアーキテクチャ。GoやScalaのような華々しい言語で実装した話はよく語られていますが、もちろん我々PHPerの愛するPHPでもできるんです！
私は2018年〜PHPシステムのマイクロサービス化プロジェクトを始め、2021年現在もPHP製マイクロサービスを運用・進化させています。PHPシステムの中でマイクロサービスに向く機能・PHPマイクロサービスをどうやって作って運用するかまでお話しします。
(1)マイクロサービスとは？
(2)PHPでマイクロサービスの作り方（設計、コード）
(3)AWSでPHPのマイクロサービスを動かすための仕組み

kubotak-is/php-delというPHPコードをComposer Bin Commandを利用して消すライブラリを作成しました。
特定の形式でコメントを書いておくと、そのコメントを基準にPHPコードを削除します。
なぜそんなライブラリを作ったのか、その実装はどのようになっているのかを紹介します。
このセッションではComposer Bin Commandの作り方や自作のComposerライブラリをpackagistで公開する手順などを学ぶことができます。

中小ベンダーのエンジニアとして、有象無象のWebシステムの開発や保守に関わる中で、本当にあった、身の毛がよだつようなアプリケーション脆弱性のお話や、笑えないセキュリティインシデントのお話を、怪談風に（・・・の予定で）お話しします。

第一話は、他社から保守を（引き継ぎなしで）引き継いだ、証券会社の顧客向けマイページシステムが、恐ろしい脆弱性だらけだったお話です。

調査結果の一次報告のとき、「このことは口外禁止でお願いします。明るみに出ると死人が出ます」と言われたことが今でも忘れられません。

第二話は、WordPressサイトが攻撃されて相談を受けた数々の事例の中で、一番悲惨だったお話。

時間が許せば、自社のやらかし（未遂）事例などもお話ししようと思います。

去年、「オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)」を読みました。その中で、デザインパターンの1つ「Observerパターン」の紹介がされています。「そういえば、今まで使ってきたフレームワークの中でObserverパターンの処理があったな」「でも、微妙に記述方法が違ったな？」「それぞれの違いを比較してみたいかも！」となりました。

• CakePHPに見るObserverパターン「CakeEvent」
• Laravelに見るObserverパターン「Laravel Observer」

どのように使うのか？どのような実装がなされているのか？それぞれのいいところ・・・ナドナド、「Observerパターン」の基本的な説明も含めて、時間の許す限りまとめます！

オンライン決済サービスStripeを利用することで、少ないコードで複雑な料金体系の定期課金や決済機能を実装することができます。
また、Webhookを利用したバックエンドシステムへの組み込みや自動化、CRMなどとの連携も難しくありません。

このトークでは、PHPの実行環境としてAWS Lambdaを利用し、以下のトピックについて紹介します。
・AWS LambdaでPHPを利用する方法（Serverless Framework）
・AWS Secrets Managerを利用した、安全なAPIキー運用
・Stripe / Stripe Webhookを利用した定期課金の実装やサービス連携方法

AWS Lambdaに限らず、
AWS上でPHPとStripeを利用したWebアプリケーションを開発する際に意識したい点やアーキテクチャのヒントについてもお話ししたいと思います。