webサービスを開発する上で、脆弱性への配慮は非常に重要です。
皆様も一般的な脆弱性については意識をされているかと思います。しかし、マイナーな脆弱性についてはどうでしょうか?
本セッションでは Laravelにおいて実装された5c問題の脆弱性を持つデモ用のweb applicationを攻撃し、脆弱性の説明を行います。
対象
内容
文字コードの知識を活かしたsql injectionの防止を通じて、セキュリティへの関心を高めましょう。
webサービスを開発する上で、脆弱性への配慮は非常に重要です。
皆様も一般的な脆弱性については意識をされているかと思います。しかし、マイナーな脆弱性についてはどうでしょうか?
本セッションでは laravelにおいて実装された5c問題の脆弱性を持つデモ用のweb applicationを攻撃し、脆弱性の説明を行います。
対象
内容
文字コードの知識を活かしたsql injectionの防止を通じて、セキュリティへの関心を高めましょう。
この発表では、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とドメインフロンティングについて
・実際に発生する問題とその解決方法
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で動かすことを前提に、ジョブ実行の様々なパターンについて特徴を説明します。
事例として、オンプレからの移行時にキューイングサービスを利用しスケーラビリティを得られた話なども交えてお話しします。
開発環境を柔軟に構築でき、それを簡単に共有できる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分でサクッとお伝えします。
実際に運用していてまったくストレスを感じていない方法なので、ちょっとでも困っている人には明日からすぐにお役立ていただける内容だと思います!
みなさん普段FigmaやFigJamを使っていますか?
私はよく使っていて、特に好きな機能は「カーソルチャット」です。
複数人でリアルタイムにカーソル位置を共有できたり、ライブメッセージの送信を行うことができたりなど、使っていて楽しいです。
この素晴らしい機能を他のWebアプリにも組み込むことはできないかと考え、 カーソルチャットのReactライブラリを作ってみました!
このLTでは自作ライブラリの仕組みや、Reactアプリにカーソルチャットの機能を実装する方法、そしてReact Flowと組み合わせて簡単なコラボレーションアプリを作ってみた話をします。
開発環境を柔軟に構築でき、それを簡単に共有できるDockerですが、都度適切な環境を構築することが新米エンジニアの私にはとても高いハードルでした。
しかし、ある出来事によりそのハードルがここ最近ガクッと下がりました。AI技術の急速な進化です。
このLTではAIツールを活用して0からDockerでLaravel環境を構築できた実体験をお話しすることで、
Docker × Laravel環境の作り方をわかりやすくご紹介すると同時に、プログラミングにおけるAIツール活用のコツも少しご提供できればと思います。
コードを書いていて自分で命名をする機会って多いですよね。
良い命名をすることで、コードの可読性が向上し、保守性も高まります。一方、悪い命名はコードの理解を困難にし、ソフトウェア品質を低下させる原因となります。
実体験、書籍、ウェブ記事や他のカンファレンスで学んだことを総合的にみて、どんな命名をすべきかを具体的なコードを示しながら発表します。
本発表の目的は、良い命名の条件と具体的な命名方法を理解し、実践につなげることです。
内容
PHPで文字コードを扱うには、mbstringを使うのが主流であると思います。
そんなmbstringですが、PHP 8.1からMajor Overhaul of mbstringという大規模改修が入ったため、その内容を把握するための記事を書きました。
運良く、執筆者であるAlexさんに読まれたことで、ぼくはPHP 8.3となるバージョンの面倒を見るという立ち回りをしています。
文字コードはそれぞれ生まれも管理の方法も違うため、色々と混乱することもあるでしょう。
特にShift_JISのたくさんの亜種などはたくさんありすぎて何がなんだかわかりませんよね。
そういったものを紹介していければいいなと思っています。
また、PHP 8.3では、どうやらUTF-8を使うのがよさそうというのがわかってきました。
一方で、Shift_JISやISO-2022-JPなどを使うというのも選択肢としてあるようです。
それにはUTF-8特有の弱点も存在していて、Shift_JISが好まれる理由でもあるようです。
文字コード、それぞれ先人の歴史の積み重ねによるものが多いです。
一度、棚卸しを兼ねて文字コードを見てみませんか。