この発表では、Laravelを使ったWebアプリケーション開発において、誤った実装やセキュリティに関する不注意によって生じる脆弱性(XSS、CSRFなど)について説明します。また、それらを回避するための対策方法について説明します。
主な対象
話すこと
PHPアプリケーションのコード品質を上げて、メンテナンス性をあげて、寿命を伸ばすためによく使われるようになったphpstan。
皆さんのプロジェクトのphpstanのlevelはいくつですか?baselineは解消できていますか?
SymfonyやLaravelで作ったアプリケーションに対してlevel:maxを設定してbaselineなし・エラーなしにした経験から、コードを書くときに気をつけること&phpstanを納得させるテクニックをLTの5分にギュッとまとめてお伝えします。
昨今、SNSやWebsiteビルダーによってインターネットでの情報発信の敷居が低くなっています。また、インターネットでの情報発信が当たり前だからこそオリジナルなポートフォリオサイトやコーポレートサイトを作る機会も増えていると思います。そのような場合、サイトオーナーが更新できる環境として、WordPressをレンタルサーバーにインストールしてカスタマイズする構成が多く採用されていると思います。
WordPressは多くのプラグイン、大きなコミュニティというエコシステムが便利ではありますが、サイト構築のためのソフトウェアです。一方で、第2の脳と呼ばれるNotionは、散り散りになったWeb上のツールを一つに集約し生産性を高めるソフトウェアが人気を博しています。Notionを使う前提になりますが、インターネットの情報発信に使うコンテンツもNotionで管理し、そこからNext.jsを使ったStatic Websiteとしてビルドすると、安価でハイパフォーマンスなサイトが構築できるというわけです。また、Notionのデータベースは非常に柔軟性のあるカラム定義ができるため、Websiteの仕様に応じて設計することができます。
Notion APIからStatic Websiteを作るのは骨が折れます。なぜかというと、Notionに埋め込まれた画像やデータはNotionの認証に守られているため、ローカルにダウンロードする必要があります。また、Notionには何百という外部サービスの埋め込み機能があるからです。ですので、その苦労を肩代わりしてくれるNotionateを使うと手軽に先述のことができるのです。
Notionateは私が開発しているソフトウェアです。その開発においての苦労や工夫した点をご紹介します。例えば、Notion APIのRatelimitにかからないように何をしているか。サイトが大きくなるとビルド時間が比例して長くなります。その緩和のための差分ビルドをどのように実現しているか。などです。また、Static Websiteだけでは補えないケースを、PHPで作ったAPIの例もご紹介します。
皆さん単体テストを書いていますか?
Webサービスを保守・運用していると、追加開発する際に機能の冪等性(べきとうせい。何度同じ操作をしたとしても同じ結果を得られるという性質)が求められることもあると思います。特にインフラにAWSを利用している場合、AWSリソースへのアクセス部分のテストをどのようにするか悩みますよね。
LocalStackを利用すると、ローカル環境でAWSクラウドサービスをエミュレートして、アプリケーションのテストを実行することができます。更に、GitHub Actionsで単体テストをまわすことが出来ると素敵ですよね。
今回は、Laravel(PHP)にフォーカスを当てて、LocalStackでAWSリソース(S3、DynamoDB、RDS、etc)の効率的なローカルテストを実現するとともに、GitHub Actionsで単体テストを自動化するところまで説明したいと思います。
主な対象:
・AWSを利用してWebサービス開発をしている方
・Laravel(PHP)を用いてWebサービス開発をしている方
・疎結合、密結合の単体テストの作り方で悩んでいる方
話すこと:
・LocalStackの紹介
・コンテナサービスの比較
・LocalStackを利用したAWSリソース単体テスト for Laravel(PHP)
・GitHub Actionsによる単体テストの自動化
Webサービスを運用するとき、セキュリティやコンテンツ配信の効率化といった目的のために前段にCDNサービスを置くのはよくある構成です。弊社ではMicrosoft Azure上でWebサービスを運用する際、フロントにAzure CDN(Front Door)を配置しています。
運用中のWebサービスでエラー画面が稀に表示されるという問い合わせが寄せられました。しかしエラーの再現率が非常に低く、アプリ側には何のエラーも見当たらず調査は難航しました。
そんな中で見つかった、Azure CDNでのHTTP Status 421という見慣れないエラー。我々はこれを手がかりに調査を進めるうちに、Azure CDNでのドメインフロンティング対策やHTTP/2でのコネクション再利用の仕様といった多くの情報に直面し、問題解決に至りました。
本セッションでは我々が実際に遭遇した問題とその解決に至る過程をお話しし、以下について詳しく解説します。
・ドメインフロンティングについて
・Azure CDNをはじめ、CDNサービスにおけるドメインフロンティング対策について
・HTTP/2とドメインフロンティングについて
・実際に発生する問題とその解決方法
太古の昔、サーバーの設定をいじるとなると、プロフェッショナルなインフラエンジニアにお任せだったと聞きます。
我々(PHPer)の手に負えない程大きくなったインフラの管理は、それこそ職人技だったのだと想像できます。
一方現代、インフラの多くはクラウドです。
皆さんもAWSなどを活用していると思われますが…形だけのクラウドになっていませんか?
クラウドの登場で誰でもポチポチ簡単にサーバーを建てれるようになりました。が、"本番環境にそびえ立つ謎のサーバー"や"誰も設定がわからないLB"などオンプレ時代とそう変わらない問題を大なり小なりどの現場も抱えているかと思います。
我々はいつまでコンソールの画面をポチポチしてサーバーを作るのでしょうか?
昨今IaC呼ばれる便利ツールが流行っています。ただ、メリットがわかっていても、「キラキラでなんか怖い!」「うちには導入できない!」と思われて二の足を踏んでいる方もいることでしょう。
大丈夫です。我々が「ポチポチコンソールによるAWS」から「IaCによるAWS」にマイグレーションした過程をお話します。
「最初からすごい人がいたんじゃないの?」と思われるかもしれませんが、そんな事ありません!移行の過程で一つずつコード管理を進めました。
いまあるサーバーを動作させながら少しづつIaC化しましょう!
本トークでは
・TerraformなどIaCをつかうメリットを紹介
・アプリケーションエンジニアがTerraformを使えると良い理由
・ポチポチコンソールで作成した現在稼働中のサーバーを、Terraformで管理する方法・Tips
を話したいと思います。
※話さないこと
・ツールのインストール方法や、チュートリアルレベルのお話
・PR TIMESのAWS移行時の具体的な作業の説明
本トークを聞き終わった後に、PHPerのみなさんが「自社のサーバーをIaCツールで管理したい!俺らの手でやるぞ!」と思えるトークを目指します!
echoとprintって何が違うの?
for と foreach , whileの違いと使い所って?
早いコードと遅いコードってどのくらい差があるの?
php8.2に存在するビルトイン関数をopcodeを見て感覚ではなく理論で理解しよう!
話すこと
PHP8.2のビルトイン関数の紹介
類似した関数のopecodeの比較
早いコードと遅いコードの比較と関数の得意な処理の説明
日々大量の PHP コードをタイピングする PHPer にとって快適なタイピング環境は非常に重要です。
しかし、市販のキーボードでは手に馴染まない、キーピッチが狭すぎるなど、自分のニーズに合わない場合があります。
そこで、基板から設計する自作キーボードの世界に足を踏み入れてみませんか?
このセッションでは、PHPer 向けに、自作キーボードの製作方法を紹介します。
ハードウェアの知識がなくてもおおまかな手順が理解できるように、
必要なツールや素材、発注から組み立てまで、キーボード製作のための手順を解説します。
自分だけのキーボードを作るための知識を獲得し、自分だけの理想のキーボード 「Endgame」 を作り上げ、快適なタイピングライフを手に入れましょう!
今年に PHPerKaigi 2023 というイベントで、「時間を気にせず普通にカンニングもしつつ ISUCON12 本選問題を PHP でやってみる」というトークをしました。
https://fortee.jp/phperkaigi-2023/proposal/7e212cb2-be37-43e8-b6ee-5236d259fcbf
時間無制限バトルによって、結果的には ISUCON12 の優勝チームが Go で出した本選スコアを PHP で越えることができました。しかし、このときのチャレンジではまだ幾つか試せていない取り組みもあります。
例えば他言語で行われるような、オブジェクトのプールを事前生成して使いまわすような最適化には PHP でも意味があるのでしょうか?
実行時型検査のコストをバイパスするような最適化は可能なのでしょうか?
immutable_cache のような別のキャッシュソリューションに目に見える効果はあるのでしょうか?
Workerman や他の非同期 PHP フレームワークのような、さらに異なる PHP 実行環境との性能比較はどのような結果になるのでしょうか?
思いつくままにいくつかの挑戦を追加でやってみます。
対象とする聴講者は以下です。
Psalm や PHPStan、あるいは PhpStorm などでの静的型解析の隆盛により、時には動的型の言語であることを忘れそうになってしまうのが現在の PHP という言語です。
しかし一方で PHP は古くからある言語ですから、その現代的なエコシステムの力を借りられない、ソースコード中にほとんど型情報のないレガシーコードを扱う現場も数多くあります。あるはずです。そうですよね?
このトークでは静的解析や動的解析によって PHP コードへ自動で型アノテーションを付与する方法をいくつか紹介しつつ、各手法の良いところ・悪いところを比較検討してみます。
想定する聴講者は以下です。
OpenTelemetryはObservabilityを獲得するための標準化されたSDK・API・ツールの提供を目的とした、CNCFのオープンソースプロジェクトです。
CPU使用率のようなシステムメトリクスから、アプリケーションのカスタムログまで、様々な情報を言語やプラットフォームに依存しない統一的な規格で管理できます。
モニタリングツールもJaegerやPrometheusといった主要なOSSとの連携がサポートされているだけでなく、DatadogやNew Relicのようなベンダーサービスにも出力を取り込めるようになっています。
10種以上の言語への対応が進んでいる中、ついに昨年12月、PHPのSDKがv1.0.0になりました!
4月現在まだbetaですが来たるGAに備えて、便利に使いこなすために、OpenTelemetryがどういうものか、何に使えそうかを今一度みていきます。
いまや、Webアプリケーションをコンテナとして動かすことが当たり前になってきています。インフラをクラウドベンダーにお任せできて便利です。
一方で、コンテナの思想や制約もあり、定期的にスクリプトを実行したり、SSHして別のプロセスを起動したりが、いままで通りにできなくて困った経験はないでしょうか?
当社では、オンプレ環境からAWS環境へ移行した際に、大量のcronやメール受信後の処理を置き換えることに四苦八苦しました。順序は気にしないといけないのか?冪等性は担保されているの?などなど気にすることも様々です。
本セッションはAWSで動かすことを前提に、ジョブ実行の様々なパターンについて特徴を説明します。
事例として、オンプレからの移行時にキューイングサービスを利用しスケーラビリティを得られた話なども交えてお話しします。
私はtblsというツールを開発しています。
2018年にtblsはデータベースのスキーマ情報からドキュメントを生成するツールとして誕生しました。
そして、現在も多くの企業やユーザに使われています。
ある海外のサイトでは次のように紹介されました。
The project has been open-sourced for 5+ years, but the number of stars had a spike earlier this year. Anyone has any idea what happened in between?
(このプロジェクトは5年以上前からオープンソース化されているが、今年の初めに星の数が急増した。その間に何があったのか、どなたかおわかりになりますか?)
tblsは2018年から継続的に開発しており、まだ機能的な成長を続けています。
ところで、私はドキュメント運用のアプローチとしての"Documentation as Code"について考えてきました。その一部は https://speakerdeck.com/k1low でみることができます。
tblsはDocumentation as Codeを実現したツールの1つと言えます。そしてtblsは当時考えていたDocumentation as Codeの範囲を越えようとしています。
本セッションではDocumentation as Codeのその先について、tblsの今後の展開と共に共有したいと思います。
開発環境を柔軟に構築でき、それを簡単に共有できるDockerですが、都度適切な環境を構築することが新米エンジニアの私にはとても高いハードルでした。
しかし、ある出来事によりそのハードルがここ最近ガクッと下がりました。AI技術の急速な進化です。
このLTではAIツールを活用して0からDockerでLaravel環境を構築できた実体験をお話しすることで、
Docker × Laravel環境の作り方をわかりやすくご紹介すると同時に、プログラミングにおけるAIツール活用のコツもご提供できればと思います。
SymfonyのFormTypeはフォームの定義をバックエンドとフロントエンドで共有できる非常に強力なツールですが、
FormTypeの一種で<select>などの選択式フォーム項目の選択肢をエンティティと自動でマッピングしてくれる「EntityType」を使う際には、
パフォーマンスの面で気をつけなければならない点がいくつかあります。
特に重要なのは、N+1問題の考慮です。大量のレコードを持つエンティティに対して無造作にEntityTypeを使ってしまうと、しばしばN+1問題が発生し、意図せず大量のクエリが発行されてしまいます。
また、<select>のユーザー体験を向上させるためにSelect2やselectize.jsなどのライブラリを導入してインクリメンタル検索などを実現することはよくあると思いますが、EntiyTypeによってエンティティのレコード数だけ<option>を持つような<select>が出力されてしまうと、Select2やselectize.jsの初期化処理に数秒オーダーの時間がかかってしまい逆にUXが悪化するといったこともよく起こります。
Symfonyユーザーの多くがEntityTypeが持つこれらの問題に長らく苦しめられてきましたが、実はそれも今は昔。
Symfony UX Autocompleteというライブラリの登場でこれらの問題は完全に解決してしまいました。
Symfony UXは、Symfonyアプリケーションにフロントエンドの処理を簡単に追加するためのライブラリ群で、その中でも私の一押しがSymfony UX Autocompleteです。
このトークでは、上述のEntityTypeの問題をSymfony UX Autocompleteによって完全に解決するまでの手順と実際のユーザー体験の変化を具体的にお伝えします。
話すこと:
・Symfony UX Autocompleteについて
・EntityTypeが使われているSymfonyアプリケーションへのSymfony UX Autocompleteの導入方法
・Symfony UX Autocomplete導入前後のユーザー体験の変化について
話さないこと:
・Symfonyの基本的な使い方
・Autocomplete以外のSymfony UXライブラリについて
Macで複数バージョンのPHPを使い分けるのって意外と難しくないですか?
Docker経由でしかPHPを使わないみたいな猛者スタイルで行ければいいのかもしれませんが、
パフォーマンスや開発体験の問題からローカルのPHPを使いたい事情もあると思います。
phpenvやsymfony-cliと.php-versionファイルを併用すればディレクトリごとに使用するPHPバージョンを指定することもできますが、
この辺はいざ導入しようとするとYak Shavingの嵐が待っていて(実体験)非常に面倒だったりします。
というわけで、このLTでは私がMacのローカル環境で複数バージョンのPHPを楽に使い分けるために実際にやっていることを5分でサクッとお伝えします。
実際に運用していてまったくストレスを感じていない方法なので、ちょっとでも困っている人には明日からすぐにお役立ていただける内容だと思います!
現代のフロントエンド開発は、過去と比較して複雑化が進んでおり、HTMLの仕様に対する意識が低下しがちです。アクセシビリティの向上がますます重要視される中、HTMLはその基礎であり、正しい仕様の理解と実装が不可欠です。しかし、HTMLの仕様は想像以上に複雑で、WAI-ARIAなどの関連技術も含まれています。
このライトニングトークでは、Markuplintというツールを開発者が自ら紹介します。
Markuplintを導入することで、開発者は複雑な仕様を覚えることなく、リンターが問題点を指摘し、開発に集中できるようになります。
内容:
このトークを通じて、参加者にMarkuplintの有用性を理解していただき、より品質の高いWeb開発が行われることを期待しています。
みなさん普段FigmaやFigJamを使っていますか?
私はよく使っていて、特に好きな機能は「カーソルチャット」です。
複数人でリアルタイムにカーソル位置を共有できたり、ライブメッセージの送信を行うことができたりなど、使っていて楽しいです。
この素晴らしい機能を他のWebアプリにも組み込むことはできないかと考え、 カーソルチャットのReactライブラリを作ってみました!
このLTでは自作ライブラリの仕組みや、Reactアプリにカーソルチャットの機能を実装する方法、そしてReact Flowと組み合わせて簡単なコラボレーションアプリを作ってみた話をします。
最近LaravelのスターターキットであるLaravel BreezeにもTypeScriptサポートが追加されたように、LaravelにもTypeScriptを導入したフロントエンド開発需要が高まっています。
しかしTypeScriptでの開発を行っていると、Laravel側のコードと重複している箇所が多くあると感じます。
例えば
OpenAPI Specificationなどを利用してのフロントエンドコード生成やバックエンドのAPIテストを行うことでこれらの問題は解決されるかもしれませんが、APIスキーマファイル運用コストや開発速度の観点から採用が難しい場合もあります。
さらにInertia.jsなどそもそもAPIの送受信処理を省いてしまっている構成の場合にはこのようなAPI仕様書は有効ではありません。
そこで私はLaravelのModelからTypeScriptの型などを生成できるライブラリを自作し、ライブラリとして公開しました。
これを実際に業務でも採用しており、バックエンドとフロントエンドでの型共通化による開発の効率化やバグ防止に繋がったと感じています。
その他にもLaravelのバリデーションルールからTypeScriptのバリデーションライブラリZodのコード生成を行うライブラリを作成したりなど、バックエンドとフロントエンドでコードの重複をなくす取り組みを行っています。
本セッションではLaravel(PHP)のコードから型定義などのTypeScriptコードを自動生成する仕組みを導入することでコード重複問題を解決し、効率良く型安全なフロントエンド開発を行う手法を紹介します。
開発環境を柔軟に構築でき、それを簡単に共有できるDockerですが、都度適切な環境を構築することが新米エンジニアの私にはとても高いハードルでした。
しかし、ある出来事によりそのハードルがここ最近ガクッと下がりました。AI技術の急速な進化です。
このLTではAIツールを活用して0からDockerでLaravel環境を構築できた実体験をお話しすることで、
Docker × Laravel環境の作り方をわかりやすくご紹介すると同時に、プログラミングにおけるAIツール活用のコツも少しご提供できればと思います。