トーク

※こちらのトークは、9/24 Track3 15:15 から、9/25 Track4 13:20に移動しました

私が担当するSaaSプロダクトは15年続くサービスで、メインシステムはいわゆるレガシーシステムになっています。
そんなプロダクトで、新機能実装にあたり新たに小規模なサブシステムを構築することになりました。
メインシステムとはある程度切り離されたシステムなので、せっかくならモダンな技術を存分に取り入れたい！と思いつつも、環境面の制約や既存資産の流用、チームメンバーの学習コストといった課題も考慮しながら技術選定やアーキテクチャ設計を行う必要がありました。
そして検討の結果、既存資産を一部活用しながらも、新規要素としてフレームワークにはSlimを採用し、アーキテクチャはオニオンアーキテクチャ（風のアーキテクチャ）を取り入れることにしました。

このトークでは、Slimを使ったアプリケーション構築の一例として、サブシステム構築時に考慮した技術選定・アーキテクチャ設計のポイントをご紹介します。

コンピューターの処理性能が向上したこと、より大容量で安価なストレージが多く開発されたことにより、大量のデータを活用することが可能になった。
その大量のデータを活用する手段として様々なNoSQLが開発された。
なぜNoSQLが必要なのかを切り口にNoSQLについて色々とお話しします。

話すこと

・NoSQLとは何なのか。なぜ必要なのか。
・NoSQLにはどのような種類のものがあるのか。
・どういう場面で活用すべきなのか。

プログラミングを始めてから、一定のペースで「プログラミング歴」が伸びています。
最初の1年、暫く経った5年、それすらも超えて10年・・・と時間は流れていきますが、それでも変わらないのは「学び続ける課題がある」という事です。
環境の変化も伴いながら、それでも学び続けるのです。
例えば「後輩や部下に対して指導するようになった」とか「マネジメントの仕事が増えて、業務でコードを書く時間や必要性が減った」など。

学習方法や身につけるべきスキル・知識などは千差万別で、一般化して語ることは難しいですが、「いちヒントとして、どのような姿勢で学びを得ていく事が出来そうか」を本セッションで共有します。

参考にしそうな書籍など(仮)

• アプレンティスシップ・パターン
• スーパーエンジニアへの道
• ソフトウェア職人気質
• Clean Craftsmanship
• プログラマが知るべき97のこと

PHPerなら必ずと言っていいほどお世話になったことがある Composer ですが、自作したプログラムを Packagist に登録することは馴染みが薄い方も多いのではないでしょうか。
自作したプログラムを世界中のPHPerに配布する際、Packagist に登録するだけで Composer からインストールしてもらえるようになります。
ですが、せっかくインストールしてくれたユーザには、そのプログラムの内容をできるかぎり明確に伝えたいですよね。

本LTでは、自作したプログラムを Packagist に登録して世界中の PHPer に配布する際に気を付けたいことと、PackagistのWebの閲覧画面を確認する際に知っておくと良いポイントについてお話できればと思います。

■話すこと

・composer.json の書式に関する基礎知識
・Packagist への登録方法と閲覧画面で確認したいポイント
・親切な composer.json の書き方

■この発表をご覧いただくことで得られること

・composer.json の基礎知識
・Packagist への登録が想像より簡単だという実感

PHPでWebアプリケーションを作る場合はデータをPostgreSQLやMySQLのようなデータベースで管理することが多いと思いますが、
その中で取引記録、センサーから取得したデータ、システムに対する操作といった時系列データを扱いたい場合があります。

しかし時系列データには以下の特徴があり、データベースで扱うことが難しい場合があります。

・時間とともに保存するデータ量が増える
・一日のデータ量が多いかつ保存期間が長い場合はデータ量が膨大になる
・データに対する操作は追記と削除のみで更新は必要ない

リレーショナルデータベースはトランザクション機能や違う種類の入ったテーブルを結合するなど複雑なデータ処理が得意ですが、
トランザクションや結合の必要ないログのようなデータを扱うには機能過多かつデータ量が増えるたびに処理が遅くなると
いった問題があります。

私が開発に参加しているサービスはPHP + PostgreSQLで開発していますが、システムに対する操作をPostgreSQLに保存しています。
通常のユーザの操作では記録されるログの量は多くありませんが、バッチ処理やデータインポートが多い環境では一日あたり数百件
のログが記録される場合があります。

このような環境ではデータベースのサイズの半分以上がログになる場合があり、処理やメンテナンス作業の遅延が発生します。

そのため、このログが増える問題に対してPostgreSQLの拡張機能であるTimeScaleDBで対応できないか検討しました。
TimeScaleDBには時系列データを管理するための以下の機能があります。

・テーブルパーティショニングによる処理の高速化
・一定期間を過ぎたデータの圧縮

また、PostgreSQLの拡張機能であり、既存のSQLをそのまま使えるため、アプリの改修無しで適用することができます。

このセッションではTimeScaleDBの仕組みや適用した場合の効果について検証した結果を紹介します。
時系列データをすでにデータベースで扱っている方や、今後扱う予定がある方の参考になれば幸いです。

PHPerが Serverless を利用してアプリケーションを構築するときに障壁となっているのが、クラウド側のPHPのサポート状況が不明であることと、使い慣れたPHPフレームワークをどのように Serverless でも利用していくかがよくわかっていないこと、という声をよくいただきます。

PHPを AWS Lambda 上で使う方法についてはWEBで調べれば多くのブログがヒットするものの、情報が溢れており様々なやり方がある中で、何がベストなのかを探っていくのは困難な状況になっています。

このセッションではシンプルに Lambda 上で PHP を動かすところから入って、既存のPHPフレームワークをどのように Lambdaの上に乗せていくかまでをお話ししたいと思います。

<想定聴講者>
以下のモチベーションがあるデベロッパー

• PHPをクラウドネイティブで使っていきたい
• モダンなアプリケーションを構築したい
• PHPで培った経験をもとにクラウドでも力を発揮したい

<トーク内容>

• AWS Lambda のおさらい
• Lambdaの上でPHPを動かす
• dockerコンテナを使ったPHPアプリケーションのデプロイ
• Lambdaの上でPHPフレームワークを動かす

ライセンスの都合でローカル環境での開発環境構築が不可能な、CMSに密結合したWebサービス。
CMSの仕様に引っ張られてトリッキーな実装がされることもしばしば…といった状況もありました。

そんなJava製CMSを利用して構築していたサイトを、2年間かけてPHP + Laravel にリプレイスしました。
ソースコード管理もGitで管理でき、EC2で動いていたサイトをDockerを用いてローカルでの開発も同時に実現しています！
ステージ環境やプロダクション環境はAWSサービスである、Fargate、Codeシリーズを活用でき、柔軟にスケーリングできるようになりました。
CMSに密結合していた部分もLaravelに変更することで、モダンなサイト開発体制に近づけることができました。

この発表では、10年以上運営されている大規模な求人サービス「はたらこねっと」でのリプレイスプロジェクトにて、工夫した点や苦労した点についてお話しします。画面は数百単位、PHPのコードだけで数千単位、単体・結合テストの項目数は数万単位のプロダクトです。
コード面やアーキテクチャでの工夫、継続的な開発を意識したCI/CDの活用、監視体制の改善など様々なチャレンジをしながら、リリースを実現しました。
本トークは中〜大規模なサービスリプレイスをお考えのオーディエンスにとって参考になるトークになるものと思います。

またリプレイスや現在の開発・運用も協力会社の方とともにやっています。
大規模なプロダクトなので、参加人数が多くなりチーム体制やマネジメントといったところも試行錯誤しています。
現状の開発体制も踏まえ、協力会社と一緒に開発するという組織づくりやチーム体制についても参考になれば幸いです。

このリプレイスを通して特に活用できた技術は下記です。

• PHP
• Laravel
• PHPInsights
• Docker
• DataDog
• NewRelic
• AWS
  • Fargate
  • CodeBuild
  • CodeDeploy

みなさん、フレームワークや独自実装を用いて、ファイルのアップロードを対応しているプロダクトも多いのではないでしょうか。
実は私は、画像や音楽ファイルを含めたファイルのアップロードが、おそらくプロダクト開発をする上で苦手だなと感じることが多々あります。
「$_FILES を参照するだけでいいじゃん」そう思う人もいると思います。しかし、ファイルのアップロードというのは、より気を使わなければいけないことが多々あります。拡張子だけで、特定のファイル、例えば image.jpg というファイルの中身が png で送られている場合などもあり得ます。これはまだかわいいレベルです。そしてこれよりも悪質なものをアップロードされてくる場合もあり得ます。
以前、PHP を用いたファイルアップローダーサービスを一時的に運営しておりましたが、実装の際に、気をつけていた脆弱性や攻撃などを、フレームワークや独自実装において気をつけるべきアップロードされたファイルへの対応についてお話できればと思います。

ユニットテストを生き甲斐としているPHPerが、ユニットテストの魅力を語ります。
プロダクト側のメリットではなく、いちエンジニアとしてのスキルセット向上に関して話そうと考えています。

スキーマ駆動開発してますか？

一応OpenAPI(Swagger)書いてるけど、実装と乖離して放置されてませか？

レスポンスクラスなどをきれいに書こうとしたものの、データクラスが増えて面倒になっていませんか？

これまで2年以上開発してきた経験から、スキーマ駆動開発の勘所をご紹介します。

正しくOpenAPIを書いて、OpenAPI GeneratorやPostmanを使いこなせば、リクエスト&レスポンスのデータクラスやAPIクライアント、テストコードが自動生成できます。

本トークでは最大限OpenAPIを使い倒して、楽に効率化することを目指します。もちろんスキーマと実装の乖離は絶対におきず、複雑な設定ファイルは必要ありません。

PHPを前提に話しますが、多くの部分は他の言語で応用可能です。結合テストの実行で少しDI（Dependency Injection）が出てきますが、DIの考え方など基礎的な内容に触れません。

■話すこと
・スキーマ駆動開発とはなにか
・スキーマ駆動開発のメリットとデメリット
・OpenAPIとは
・OpenAPI GeneratorでAPIクライアントの自動生成
・スキーマと実装をずれないようにする
・Postman（Newman）で結合テストの自動生成
・DIで副作用を防ぐ

■話さないこと
・OpenAPIの詳しい書き方
・DIの考え方
・DIのライブラリについて
・npmについて

■想定対象者
・スキーマ駆動開発をやってみたい人
・スキーマ駆動開発をしているが、実装がスキーマとズレて困っている人
・APIの結合テストを自動作成したい人

『個人情報漏洩』
おそらく多くの方が経験したくないインシデントのひとつでしょう。そんな個人情報漏洩が起こってしまった後、開発者にはどんな影響があるのでしょうか？
これは1人の開発者が個人情報漏洩事件の後に感じた、開発者への影響と心境の変化のおはなしです。

※個人の感想です
※企業の被害や対策内容についてはお話ししません
※PHPのコードが1行も出てこない可能性があります

みなさんモビングしてますか？
モビング（モブプログラミング、モブプロ）とは複数人でプログラミングを行うことを意味します。
なぜモビングをやるのか？ どうやるのか？ ペアプロとなにが違うのか？ 結局生産性はあがったのか？
ずっとモブプロするのか、ときには並行作業するのか？

マーク・パール著「モブプログラミング・ベストプラクティス 」を実践してみて学んだことをギュッと圧縮してお話しします。

明日から役立つモブプロのエッセンスをお伝えできたら幸いです。

「 え！？4分でモブプログラミング・ベストプラクティスを！？ 」

マーク・パール著「モブプログラミング・ベストプラクティス 」を実践してみて学んだことをギュッと圧縮してお話しします。

みなさんモビングしてますか？
モビング（モブプログラミング、モブプロ）とは複数人でプログラミングを行うことを意味します。
なぜやるのか？ どうやるのか？ ペアプロとなにが違うのか？
明日から役立つモブプロのエッセンスをお伝えできたら幸いです。

派手なSQLインジェクションは一般的なWebフレームワークを使用すれば基本的に発生しません。
しかし、LIKE検索を行う場合はDoS攻撃が成立してしまうことがあります。

LIKE "%a%b%c%d%e%e%f%g%@%.%"

上記のようなクエリはSQLエンジンに大きな負荷をかけます。
LIKE句のメタ文字はエスケープする必要がありますが、

$query->where('hoge', 'LIKE', '%' . $value . '%');

と直に書いてしまうケースは多いと思います。

LaravelでのこのLIKE句のインジェクション対策はおそらく３通りほどあると思うので、
それぞれのソリューションをご紹介していこうと思います。

API定義のSwaggerUIやデザインカタログのStorybookなどの静的ファイルを社内展開する際にどのようにアクセス制御してますか？
AWSを利用している場合はCloudFrontとCognitoを組み合わせることで簡単に閲覧制限の仕組みを作ることができます。
弊社ではSchemaSpyで生成したER図をこの仕組で社内共有しています。
この仕組の作り方についてサクッと！紹介したいと思います！

PHP に新機能を追加したい！そう思ったことはありませんか？
もちろん PHP にはそれを実現してくれる Extension の機構がありますが、"言語として必要な機能だから PHP 本体に入れたいんだ！" ということも...

今回は PHP 8.2 に対する Random Extension 5.x を例として、 PHP に新機能を提案・追加するプロセスについてお話します。

※ このセッションは次のロングセッションのプロポーザルから RFC 周りに焦点を絞った短縮版となります
https://fortee.jp/phpcon-2022/proposal/c39b64af-506c-4b05-996c-bdb6df21ddc6

何かと話題の PHP の疑似乱数生成器。 "壊れたメルセンヌ・ツイスタ" は有名ですが、関数のエイリアス化により発生した問題やモジュロバイアスの問題、
初期シード値の生成に関する問題など、様々な問題を抱えていたのはご存知でしょうか？

今回はそんな PHP の疑似乱数生成に関わるディープなネタを改善の歴史と共に振り返ります。

※ このセッションは次のロングセッションのプロポーザルから乱数周りに焦点を絞った短縮版となります
https://fortee.jp/phpcon-2022/proposal/c39b64af-506c-4b05-996c-bdb6df21ddc6

PHP では言語に対する変更に対し必ず RFC (Request for Comments) 文章を作成し、投票で一定数以上の票を獲得する必要があります。
またその提案に対する議論は必ず Internals ML と呼ばれるメーリングリストにて英語で行う必要があります。

上記のようなハードルの高さからか、比較的 PHP の利用率が高い日本からの新機能の提案、実装の例は少ない印象ですが、実際にやってみるとどうなのでしょうか。

今回は RFC を作成、実装し、 PHP 8.2 で実装が決まった Random Extension 5.x を例に PHP への新機能追加・変更を行っていくまでの道のりについてお話できればと思います。

PHPカンファレンスの初期の頃から続けている初心者向けのセッションです。
ショートセッションでPHPの概要と手元で実行する環境、簡単なコードの紹介をいたします。

PHPのご紹介
PHPを試せる環境
PHPはどんな言語か

このセッションをお聞きいただけるとPHPがどのような言語かを理解することができます

・対象となる方
このセッションではPHPを普段使われていない方、プログラミングを始めて間もない方を対象としています。
・対象とならない方
ご自分でマニュアルを見て環境設定、プログラミングが出来る方は対象外です。

PHPカンファレンスの初期の頃から続けている初心者向けのセッションです。

PHPとはどんな言語か
PHPの実行環境にはどんなものがあるか
スクラッチでのPHPの書き方の基本

このセッションをお聞きいただけると手元で簡単なPHPのコードを実行することが出来るようになります。

・対象となる方
このセッションではPHPを普段使われていない方、プログラミングを始めて間もない方を対象としています。
・対象とならない方
ご自分でマニュアルを見て環境設定、プログラミングが出来る方は対象外です。