■ 背景
サービスの管理用システムや社内専用システムはどの様にアクセスを制限していますか？
外部からアクセスができないよう会社のIPアドレス限定でアクセス許可を行う形が多いかなと思います。
しかし、これでは在宅勤務時など社外からアクセスできない弊害が……。
そこで、Google CloudのIdentity-Aware Proxy(IAP)を利用し、クローズドなサービスにどこからでも安全にアクセスできるようにします。

■ お話すること
・IAPを活用してサービスを守りつつ、安全にクローズドなサービスを公開していくための構成やポイントをお話します。
・IAPで認証されたことを前提に、パスワードレスで利用できるサービスとしたPHPのコードも交えてお話していきます。

■ 前提
・Google Cloudを利用した構成についてのお話です
・Googleアカウントを使った認証をベースにお話します

みなさんは CodeCrafters というサイトを知っていますか？
このサイトは少し複雑なソフトウェアを作りながらプログラミングを学ぶことができるサイトです。
このサイトではRedisやDockerコマンド、SQLite などの基本的な機能を作るような練習問題があります

Redisを作る課題にチャレンジしました。そこで学んだことを話そうとおもいます。

■話すこと
・CodeCraftersってどんなサイトなのか
・CodeCrafters で Redis を作る手順について
・Redisのプロトコル(RESP)について

■ターゲット
・PHPの基本的な文法はわかるけど次に何をするか悩んでいる人
・PHP以外の言語でなにか作りたいけど作りたいものがない人

『パフォーマンスを改善せよ！』突如下された指令...あなたはこのミッションをクリアしなくてはなりません。
しかし、「方法論を知っていても実施困難」「改善効果が測りにくい」「予測を立てづらい」などの様々な課題を抱えているのが実情です。
では、効率的に確実にこのミッションを遂行するにはどうすればよいのか？

すぱらしいソフトウェアのお医者さん、ロブ・パイクは言いました。「推測するな、計測せよ。」　なんかかっこいい。

このトークでは、この格言の通りにパフォーマンス改善に挑んだ実話を基に「効率的な正しいアプローチ」「パフォーマンス改善方法」をご紹介させてもらいます。

■話さない内容
・詳細なツールの使い方
・解析結果の読み方

■主な内容

・パフォーマンス改善方法の紹介
・パフォーマンス改善業務の進め方
・パフォーマンス改善の失敗談

我々のチームではサービスのメトリクス監視であったり、パフォーマンス可視化にNew Relicを活用しています。
また、開発プロセスの改善や活動量からエンジニアを評価出来る環境作りのために、開発チームのパフォーマンスをNew Relicで可視化、活用しています。
本トークでは、サービスのパフォーマンス可視化だけではなく、開発チームのパフォーマンス可視化も行えるNew Relicについて、弊社の活用事例を時にはコードレベルまで掘り下げながら紹介させていただきます。
サービスや開発組織のパフォーマンスの可視化にご興味のある方々に響くトークをさせていただきます！

開発をしていると「この変数は何を表しているのだろう？」とか、「この関数は何をしているのだろう？」とか、一目見ただけでは何を伝えたいのかが分からない命名を目にすることがあります。
意図が伝わらないだけであれば調べれば済むかも知れませんが、時には命名が誤解を招き大問題に発展することもあります。
そんな不幸を呼び寄せる命名をあなたも知らず知らずのうちにしているかも知れません。
ここでは実際に私が見た「君はそもそも何をされてる方なの？」と言いたくなる命名の数々をご紹介し、命名の重要性を論じていきたいと思います。

PHPで構築したシステムの監視運用について、お悩みはないでしょうか。
あるいは、「最近Obserbavilityという単語を耳にするけど、実際なに？」という方も多くいらっしゃるのではないでしょうか。

本LTでは、PHP-fpmでWordPressをAWS EC2上に構築し、
Obserbavilityの3本柱と言われるAPM, Log, MetricsがObservabilityツールの一つであるDatadogでどのように見えるかみてみたいと思います。

Obserbavilityの基礎から実際の見え方までお伝えできるよう、基本概念からお話し予定です。

PHP8.2から動的プロパティが非推奨となり将来的には禁止となることは、多くのPHPerに衝撃を与えたことでしょう。
そのような中で、例外的に動的プロパティが認められた特殊なクラスが存在します。
それが「stdClass」です。
このクラスは一体何者なのでしょう。
公式の説明を見ると「PHP には全てのクラスの親となる基底クラスの概念がないため、 このクラスは基底クラスではありません。」と記されています。

...では一体何なのか？！
現代的なコーディングにおいて動的プロパティは良くないとされ、PHPが徐々に厳格なコーディングスタイルを取り入れていく中で、なぜstdClassだけが許されているのでしょうか。
ここではstdClassの機能と用途からその正体に迫り、今後のコーディングにおいてstdClassは使って良いものなのかを説明していきます。

皆さんが使っているフレームワークは何でしょう？？
ウェブアプリケーションの開発において開発効率の向上、セキュリティの対応等のためにフレームワークを使うことが多いと思います。

私は普段はLaravelを使ってます。というか業務ではLaravelしか使ったことがありません。
他のフレームワークの様子がどうやら違うらしいという噂を聞きました。
そこで調べてみたところ、驚愕！
フレームワークによって全然違う！
調べた中で見つけた違いと魅力について、私の意見を交えて説明します。
各フレームワークの比較をして違いを理解している人は少ないかと思いますので、この発表で違いを理解しましょう！

トーク内容
各フレームワークの特徴
それぞれの設計思想、魅力
どういうプロジェクト、どういう人におすすめなのか？

対象のフレームワーク
・ Laravel
・ CakePHP
・ Yii
・ Slim

顧客情報やカード情報の流出などの問題から、サービスのセキュリティ面に対する非機能要求は年々高まりつつあります。

昨年私たちのチームで担当したアーキテクチャのリプレイスプロジェクトでは、Java製のCSMで構築されたサービスをPHP&Laravelの構成へリプレイスしました。
リプレイス前後ではサービス、機能としてのふるまいが変わらない点を重点的にテストしました。しかしふるまいに対してのテストのみでは、セキュリティ上の問題発見が困難でした。

そこで、私たちのチームではWeb脆弱性診断ツールであるVAddyを選定し、セキュリティテストを実施しました。
シナリオに沿って自動的にセキュリティテストを実施する方法や導入に関する課題、問題があるコードの発見と対処についてお話しします！

.NETというとC#というイメージでPHPerにとってはあまり関係ないものと思っていませんか？
なんとPHPも.NETのランタイムで実行することができるんです！
PeachPieというオープンソースプロジェクトがあり、それを用いることでコンパイルしたPHPを.NETランタイム上で実行し、C#とPHPの相互運用が可能になりました。

このトークではPeachPieの紹介と、実際にPeachPieを用いて個人開発してみた際の知見や感想をお話しします。

ユーザーからのお問い合わせはプロダクトを運用するにあたり避けては通れません。
原因調査にかける時間を減らし、プロダクトの改修や新機能の開発に時間を割くためには、調査ノウハウの蓄積とそれらが瞬時に引き出せることが要求されます。
これらの要件を満たす方法を模索した結果、アキネイターのように質問形式で過去事例を絞り込む方法にたどり着きました。

このセッションでは、調査ノウハウと過去事例に関して、
miroで整理を試みた際の工夫点、その仕組みを運用する際に浮上した課題点をお話しします。
また、miroでの運用の限界を感じたためkibelaでの運用も試みたのでその際の工夫点、課題についてもお話しします。

「推測するな、計測せよ」という有名なフレーズは皆様ご存知かと思いますが、今回New RelicはLaravelアプリケーションを実際に"計測"するためのポイント、そのパフォーマンスチューニングの勘所を実際の New Relic の画面を使いながら mpyw さんと一緒にご紹介します。

皆さん配列つかってますか？捨てよう！！(提案)

ご存じですか、PHPはラピッドにウェブアプリをつくれます。気軽に複雑なデータ構造を作れて幸せですね。PHPには万能薬である「PHPの配列」(配列ではない)があります！

でも…便利で愛くるしい連想配列は使っていくうちにつらい気分になっていきます。

なぜか？それはコードを駆け巡る「データ」が全く信用出来ないからです。

愛すべきPHPの配列…そんなものを捨てるなんてとんでもない？いや、捨てよう！(stdClassも)

話さないこと

• マイグレーションする方法(銀の弾丸はない、直接聞いてください)
• 「OOPとしての正しさ」

対象者

• 〜中級者
• PHP>=4

非対象者

• 連想配列でやけどしたことのない人
• テストが完璧な人(それは解法の一つ)
• 「俺はゼロイチだけやるんだ」の人

Webサービスは生き物。
機能追加によって常に成長し、変化しています。
そんな日々の中で、機能追加する際のデータベースに対する変更はつきものです。
しかし何気ないデータベースの変更が障害の元になったり、機能追加の障壁になっていたりしませんか？

• 本番にALTERを流したらロックでサービスが死んだ
• 特定のカラムを毎回確認するifの列挙が辛い
• Viewで表示されるデータがSELECTしないとわからない
• 仕様追加の際にテーブル変更が怖い

そんな不安、心配を持っている皆様に明日からできるテーブル設計についてお話します。

対象者

• 正規化をちゃんと勉強したことがない
• MySQL、PostgreSQLを使っているけどなんとなくでテーブル追加、変更をしている
• 実行計画、INDEX、言葉は知ってるけどよくわからない

同じPHPでも、単一ファイルでWebページを表示するのとフレームワークを使うのとでは書き方が大きく変わります。
みなさんは不思議に思ったことはないでしょうか？

• どうしてURLと対応するPHPファイルがなくてもHTTPリクエストを処理できるのか
• どうしてHTTPリクエストを受け取るとControllerのメソッドが呼ばれるのか
• どうしてecho等をしていないのにHTTPレスポンスを返せるのか
  そんな数々の「どうして」は、処理の起点となるindex.phpを読み解くことで答えが見えてきます。

フレームワークが動く仕組みを理解すれば適切な実装方法を判断したり、デバッグの際に役に立つでしょう。

本トークでは以下に示すフレームワークを取り上げ、index.phpを起点にフレームワークが動く仕組みを説明します。

• CakePHP
• Laravel
• Slim
• Symfony

皆さんは普段コンテナをどのように利用されていますか？

最近AWS App RunnerがPHPマネージドランタイムをサポートするなど、コンテナを手軽に利用する仕組みがますます充実してきています。

本トークでは、PHP開発でコンテナのマネージドサービスを使うメリットやPHPならではの課題についてお話しします。

話したいこと

• コンテナが使えるCaaS/PaaS
  • Cloud Run、App Runner、Fly.io etc.
• PHPの実行方式
  • mod_php、PHP-FPM etc.
• 1コンテナ複数プロセスとHTTPサーバ
• コンテナイメージのビルド方法
  • OCIイメージ、Cloud Native Buildpacks
• 非同期ワーカー、定時処理

話さないこと

• Kubernetes

カルテット開発部の2人によるLT2本立てでお送りします！

【オブジェクト指向に基づいたユニットテストの記述方法 by伊神】
ユニットテストが依存しすぎたり冗長になってしまっていませんか？社内ではその問題が起きないようにオブジェクト指向の考え方に基づきテストを書いています。オブジェクト指向に基づいた考え方いくつかピックアップしてご紹介します。

【Symfony超入門！コマンドだけでCRUD画面を作るチート法 by志賀】
SymfonyにもLaravelのphp artisan make:xxxのような公式コマンドがあります。それを使って、たった数コマンドでCRUD画面ができちゃうチート法教えちゃいます！これであなたのSymfonyチョットデキル

OPENLOGIでは10年もののPHPアプリケーション(Laravel)が日夜動き続けています。
コードの行数は数十万行あり、データベースのレコード数も数十億程度あります。

もしシステムが止まってしまったら、倉庫のオペレーションが止まり、ユーザの手元に商品が届かなくなります。
システムを安定的に動かし続けるために、「監視周りの強化」や「パフォーマンスチューニング」など様々な取り組みをしています。
また、次の10年改善し続けるための基盤作りも積極的に行なっています。

具体的に取り組んでいることについて幾つか紹介します。

コードのレガシーさには計測できるレガシーさと計測できないレガシーさがあると考えています。
私自身、計測できないレガシーさをうまく察知し、それを「コードの不吉な臭い」として感じ取るのは得意ではありません…。
しかし、

• コードはどれくらい大きいか？
• 重複コードはあるか？
• コーディング規約が守られているか？
• 循環的複雑度は？
• コードにエラーはないか？
• etc

このような情報は各種ツールを利用することで計測できます。
計測した数値を活用することで「コードの不吉な臭い」が少しずつ見え、実際にどこに手を加えて改善・リファクタリングをしていくと効率がよさいか？という道筋が見えてきます。

本トークでは主にツールで計測できるコードのレガシーさに着目しながら、どのようにコードを改善していけるか？をお話しさせていただき、皆様のリファクタリング活動の一助となればと思っております。

PHP 8.0に鳴り物入りで導入された新機能「アトリビュート」みなさん使っていますか？

コードに構造データが埋め込める？ PHPDocより良い？ 互換性がちゃんとしてる？「機能の抽象的な実装と、アプリケーションでの具体的な利用を分離でき」て、インターフェイスより柔軟？デコレータと同じようなものらしい？ PHP 8でよくわからんけど#[ReturnTypeWillChange]って書いたよ？

などなど、なんか #[] って感じで書くんでしょという以外は得体の知れないものとしてPHPer界隈に横たわっています。本トークではアトリビュートへのアクセス方法、文法から制約、作例まで20分に凝縮して説明します。Attributesで実現するPHP8時代のバリデータもご参照ください。