Laravelには便利な機能がたくさんあります。
Eloquent、Facede、サービスコンテナ、認証、ミドルウェア、Blade、artisanコマンドなどなど…
さまざまな機能を活用することで、スピード感のある開発ができることは間違いありません。
ただ、それらにどっぷり依存することによる弊害も少なくないでしょう。
あまりにも依存しすぎると、ビジネスの変化への対応による作り直し、各機能のバージョンアップの際に思わぬ量のコード修正になってしまうことがあります。
そんなことを想定し、Laravelのコードからドメインのコードが独立するよう、主にInterfaceを利用してドメインロジック(=わたしたちのコード)を切り出すことを心がけています。
Laravelでプロダクト開発を行う中で、どのようにしてLaravelのコードとドメインのコードの距離を保っているかを紹介させていただきます!
Webアプリケーションではさまざまな事情からSQLを発行したくなることがあります。
PHPでSQLを発行する際のベストプラクティスのひとつはPDOを使ってパラメータをバインドすることですが、残念ながらこの方法では可変個の要素に対して文字列組み立てを避けられません。
今回のトークでは私が社内ライブラリを再実装した「憂鬱なSQLのためのアレ、またはPDOと仲良くして枕を高くしてねむる」で紹介したライブラリを2022年にどのようなコンセプトで再設計したのかを紹介します。
PHPは読み書きがしやすくユーザーによるコンパイルが不要な素晴らしい言語です。その魅力的な構文と特性を支える素晴らしい立役者がいることをご存知でしょうか?本トークでは私たちが愛してやまないPHPの裏側を紹介します。
対象者
話すこと
話さないこと
PHPの配列(HashTable)は内部的には2つの実装で表現されています。1つはキーがそのまま添字となる配列、もう1つはハッシュ表を用いる連想配列です。
キーがそのまま添字となる配列(PackedArray)は、PHP8.2からzval構造体の配列となり、Bucket構造体が不要になりました。
このトークでは、PHP8.2におけるHashTableの解説と、HashTableからデータを探索する処理(zend_hash_lookup)、PackedArrayが通常の連想配列へ変換する処理(zend_hash_packed_to_hash)についての説明を行います。
PHP 8.1 で readonly property が登場したのも束の間、PHP 8.2 では遂に readonly class がサポートされるようになりました。
近年主立った言語でサポートされることが増えた「不変」であることが保証された変数やクラス。
PHP でもこれらの機能がサポートされたことで、中〜大規模なアプリケーションにおいてより堅牢なアプリケーション、つまりバグを生みにくく、保守しやすいコードを書くことができるようになりつつあります。
本トークでは readonly class を使う理由、そして実際に使って日々開発をする中で得たリアルな知見をお伝えしたいと思います。
近年、ECサイトなどにおいてクレジットマスターと呼ばれる、ランダムにクレジットカード番号を生成してECサイトのクレジットカード入力欄を用いてオーソリチェックをかけまくるという迷惑極まりない攻撃が増加傾向となっています。
私の関わるサービスでも例に漏れず攻撃を受けたことがあり、その対策に追われました。
今回はLaravelの機能を用いての対策や、もう一歩踏み込んだ対策を行ったのでご紹介してみようと思います。
内容
こんな人向け
昨今のChatGPTをはじめとした生成系AIはますます盛り上がりを見せており、いくつもの企業が生成系AIを利用した事業の発展を宣言していたりします。
そんな中で、自分が携わるプロダクトでも生成系AIを導入したので、その背景や過程について共有していきたいと思います。
まず、なぜ生成系AIを導入しようと考えたかの背景や、その検証のさいに困ったこと、そして助かったことなどについて話します。
次に、生成系AIで利用したAzureのOpenAIサービスについて、できることを簡単に述べたのち、実際にどのように実装したのかについて紹介し、AIが生成するものの不確実性との戦いについても簡単に見ていこうと思います。
最後に、生成系AIを導入した結果どうなったかが表れていると思うので、その結果について共有しつつ、今後の生成系AIの発展についても紹介したいです。
PHP はデータベース通信、ファイル操作などの I/O バウンドなユースケースで多く使われています。
これまでの PHP では I/O 処理でブロックし、処理が終わるまで待機する仕組みになっていましたが、 PHP 8.1 から Fiber がコア実装に含まれたことにより、 PHP でも非同期な処理をサードパーティ extension なしでより簡単に実装することが出来るようになりました。
中でも注目を集めるライブラリ群が amphp です。このライブラリ群は、 HTTP サーバや MySQL クエリの非同期化など様々な高レベル実装を提供しています。
今回は、現段階で実装済みの各ライブラリを紹介し、今後 PHP でも非同期処理を使いやすくなるぞ、ということを紹介したいと思います。
あなたは"良い"テストが書けていますか?
普段テストを書いている人でも、良いテストを意識して書くことは意外と難しいです。
高品質なアプリケーションを開発するためにテストは必要不可欠ですが、
品質の悪いテストが増加すると、かえって開発の足かせになりかねません。
本トークでは、15年以上の歴史を持ち、数万のテストを有するPHPアプリケーションの開発に参加して得た経験や反面教師をもとに、
持続可能で保守性の高いテストを書く方法について解説します。
みなさんは何かしらの VM (Virtual Machine)を作ったことがあるでしょうか。私自身は過去に PHP で JVM (Java Virtual Machine) を作ったことがあります。
現職は Ruby on Rails がメインの企業です。Rails どころか Ruby 初心者である私が Ruby の気持ちを理解するにはひと工夫必要だと考えました。
そこで,過去に PHP で JVM を作ったことがある経験を活かし,RubyVM を自作して Ruby の気持ちを理解し学習速度を加速させようという考えに至りました。
本トークでは PHP でどのように VM というものを作るのか,そして RubyVM はどのように作っていくのかを,初心者でも「ちょっとわかったかも」と思えてもらうことをゴールとして解説します。
Webアプリケーションは生き物です。
作って終わりではなく、日々運用を行っていかなければいけません。
しかし、日々成長するWebアプリケーションは突然パフォーマンスが問題になり、サービス障害を生み出します。
そこで今日はシンプルなLAMP環境で動くようなWerbアプリケーションのパフォーマンス・チューニングの勘所についてご紹介します。
基本的な考え方から実際の明日から役立つテクニックまで全部ご紹介します!
過去にはセキュリティの文脈で「例えばPHPを避ける」と言われたこともあったり、昨今では速度のためにRustを採用しようという技術選定のモチベーションがあると思います。
しかし、果たしてその技術選定は正しいと言えるのか。デメリットはないのか?
このトークでは私が過去に行った技術選定を紹介するとともに、その技術選定がその後どうなったか。うまく行ったのか行かなかったのか、またそこから得られたものはなにかを話します。
技術選定する際に気をつけていること、考えているポイントなども共有し、今後皆さんの技術選定の際のヒントになれば幸いです。
開発速度の優先は時にユニットテストを犠牲にします。
私のプロダクトはリリースから15年を超えてなお、テストを書くというカルチャーが根付いていませんでした。
その結果、品質問題が日々顕在化していく中で、昨今一般的であるテストを書きながら開発をする手法を取ることで品質を上げていこうという機運がチーム内で高まりました。
しかし、環境整備をしてもテストが書かれないという事例も往々にしてあります。
私たちも過去にテストライブラリ導入を行いましたが、テストはほぼ書かれませんでした。
既存プロダクトにテストを書くカルチャーを根付かせるのは難しいのです。
本トークでは、ユニットテストを書きながら開発していく環境を整備していった一連の流れとその後をお話しします。
【話す内容】
・環境整備を行った経緯・後日談
・ライブラリ移行(codeception⇒PHPUnit)
・CI運用
・テスト記述方針整備
みなさんはWebAssembly(WASM) はご存知でしょうか?
ブラウザで利用するケースはもちろんのこと、WASI( The WebAssembly System Interface) の普及で様々な利用シーンが考えられるようになりました。
そのようなWASMですが、我々PHPerにとって縁の遠い話だと感じられるのではないでしょうか?実はそのようなことはありません。
ブラウザでリアルタイムにPHPが動作するhttps://php-play.devサービスを作りました。
つまり、WASM化することによって、サーバー以外でもPHPを動作させることが可能になりました。
今回のトークでは、以下の2点をテーマにお話します。
Symfonyは、PHPのフレームワークの一つで、多くのPHPerに愛用されています。その魅力とは何でしょうか?そしてその魅力をどのように活用すれば良いのでしょうか?
このセッションでは、Laravelなど他のフレームワークが優位を占める現在でもSymfonyが一定のシェアを保つ理由、Symfonyの特性とその魅力について掘り下げます。
このセッションを通じて、他のフレームワークを使用している方に、Symfonyの可能性とその魅力を感じていただき、Symfonyを活用した開発の新たな視点を提供できればと考えています。
このセッションは、PHPフレームワークに興味がある方、Symfonyについて知りたい方に特におすすめです。
PHP には古くから PHP Extension という機構が備わっており、ネイティブで高速な言語拡張を提供することが可能です。
普段からよく利用されているであろう APCu や PhpRedis なども PHP Extension という形で提供されています。
実は、 PHP Extension 取り巻く環境が以前と比べて変わりつつあるのはご存知でしょうか?
今回はそんな PHP Extension の今について発表させていただきます。
誰かの書いたコードが世に出る過程で、コードレビューを行う組織は多いのではないでしょうか。
コードの質を担保するため。属人化を防ぐため。知識共有や認識合わせのため。チーム内のスキルアップのため。
コードレビューは様々な意味や目的を持って行われます。
本セッションでは、コードレビュワーがコードレビューイに求められていることとそれに応える方法を下記の例と共に考察していきます。
・PHPコード上でのレビュワーとレビューイのコミュニケーション例
・レビューが活性化するPHPコード例
また、実際に弊社で働く様々なポジションのPHPerエンジニアにインタビューを行い、彼らが求めるレビュー内容をもとに共通項を見つけたり、
レビュワーとしてコメントをするときの工夫点や注意点を紹介します。
レビュー時、依頼時に少しでもお役に立てると幸いです。
対象者: コードレビューを行う全エンジニア(役職問わず)
PHP 8.1から始まった、mbstringの大規模改修。
それをまとめたところ、大規模改修をしているAlex DowadさんからFYA(For Your Action)をもらうようになり、レビューをしていました。
すなわち、mbstringの変化をリアルタイムで見るようになってしまったのです。
2022年12月から始まったこのゆるい関係は、ときに入ってきたプルリクエストをサポートしたりとたくさんの出来事がありました。てきめん自身もプルリクエストを送りマージされたため、GitHub上でContributorフラグをもらえました。
また、php-src上で誰に何を投げれば良いのか段々とわかってくるようにもなりました。
本トークでは、PHP 8.3のmbstringの変更点・貢献内容はもちろんのこと、php-srcへのコントリビュートに挑戦したい方への足がかりになれば幸いです。
ノンフレームワークのプロダクトに、フレームワークを導入した経験はありますか?
計画で諦めた人、チャレンジして失敗した人もいるかもしれません。
私の開発しているプロダクトは2001年にリリースされました。
当然設計もレガシーで
・PHPファイルにHTMLがベタ書きされている
・ルーティングはページごとにxxx.phpが存在する
など、非常に”牧歌的”設計になっています。
そんなプロダクトを、Laravelに移植するプロジェクトが立ち上がりました。
誰もが無理だと思ったこのプロジェクトは
""載せる""をキーワードに設計され、無事にリリースされました!
このトークでは”載せる”をキーワードに
”載せる”戦略と、そのメリット
”載せる”ときに苦労した点
”載せた”あとの世界
についてお話します!
※このトークは、PHPerKaigi2023で行ったLTのレギュラートーク版です。
「プログラミング、上手くなりたいです!」
しばしば聞かれる質問です。
「まずはエラーを気にしましょう!」
最近はこう答えるようにしています。
プログラミング言語は、(数学や理学の世界と比べて)人工的であり恣意的な創造物です。
エラーが出ると怖い・面倒臭いと思われるかも知れませんが、
温室に氷を放置すれば溶けていくのに比べて、プログラミングのエラーは「誰かがわざとそうしている」に過ぎません。
プログラマにとって、なぜエラーが重要なのでしょう?
あるいは、PHPを作る人は、何をエラーとして何を許容してきたのでしょうか?
このトークでは、
事を試みます。
それによって、エラーと仲良くなって、「まともなコードを書ける」人が増えることを目指します。