Macユーザーの皆さんにはお馴染みのHomebrew。
Macの初期設定時のみならず、日々新たに便利なコマンドを見つけてはbrew installしていることと思います。
そんなお馴染みのHomebrewですが、裏側はどんな仕組みになっていて、コマンド自体はどこからダウンロードされているのかはご存知でしょうか?
実はこれ、とても簡単な仕組みになっていて、誰でも自分のGitHubリポジトリを通して自作のコマンドをHomebrewで配布することができます。
このLTでは、実際にPHPでCLIツールを作ってHomebrewで公開するまでの流れをお話しします。
自作のコマンドをHomebrewで公開して、世界に羽ばたきましょう!
Macで複数バージョンのPHPを使い分けるのって意外と難しくないですか?
Docker経由でしかPHPを使わない猛者スタイルなら困らないかもしれませんが、
パフォーマンスや開発体験の問題からローカルのPHPを使いたい事情もあると思います。
phpenvやsymfony-cliと.php-versionファイルを併用すればディレクトリごとに使用するPHPバージョンを指定することもできますが、
この辺はいざ導入しようとするとYak Shavingの嵐が待っていて(実体験)非常に面倒だったりします。
というわけで、このLTでは私がMacのローカル環境で複数バージョンのPHPを楽に使い分けるために実際にやっていることを5分でサクッとお伝えします。
実際に運用していてまったくストレスを感じていない方法なので、ちょっとでも困っている人には明日からすぐにお役立ていただける内容だと思います!
Doctrineは、Symfonyフレームワークの標準の構成でも採用されているPHP製のORMです。
Laravel全盛の現代、Doctrineには全く馴染みがないという方も多いと思いますが、
いつSymfony案件にアサインされるかもしれません。備えあれば憂いなしです。
それに、普段と異なるパラダイムに触れることは学びの面でもとても有意義だと思います。
この機会にDoctrineを完全にマスターしておきましょう!
このトークでは、
などについて25分で可能な限り詳しく、そして分かりやすく解説します。
SOLID原則の中でも最重要と評されることも多い「依存性逆転の原則」。
という説明は100万回ぐらい聞いたけど、正直いまだにピンと来てない・・・という人も多いのではないでしょうか。
このトークでは、そんな掴みどころがなく理解しにくい「依存性逆転の原則」について、
をとことん分かりやすく解説します!
このトークを聞けば、今まで何となく知識として知っているだけだった「依存性逆転の原則」が、
実際に日々のプログラミングの中で使いこなせる道具に変わるはずです。
乞うご期待!
API Platform は、Web APIの開発に特化したPHP向けのフレームワークです。
エンティティクラスにアトリビュートを1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう手軽さを持ちながらも、
本格的なWeb APIの開発に必要な機能を幅広く備えており、PHPでWeb APIを開発する際の有力な選択肢の一つとなっています。
このトークでは、API Platformの導入方法から、State Provider・State Processor・OpenAPIドキュメントのカスタマイズといった重要な基本機能の概要までを、
実際に動作するデモをお見せしながら丁寧にご紹介します。
皆さんにAPI Platformの概要を知っていただき、少しでも興味を持っていただければ幸いです!
API Platformは、Web APIの開発に特化したPHP向けのフレームワークです。
本格的なWeb APIの開発に必要な機能を幅広く備えており、PHPでWeb APIを開発する際の有力な選択肢の一つとなっています。
エンティティクラスにアトリビュートを1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう優れものなのですが、
ある程度複雑なことをしようとすると途端にフレームワークについての深い理解が求められ、入門と実戦の間には大きな隔たりがあります。
このトークでは、API Platformの導入方法から基本機能の概要、さらには実践投入に向けた各種ワークアラウンドや実装テクニックを、
実際に動作するデモをお見せしながら丁寧にご紹介します。
API Platformの実戦投入、あるいはその検討の一助になれば幸いです!
ユニットテストにおいて、テストダブルをうまく使うことは必要不可欠です。
しかし、それらの違いや使い分けを誤解していることも多々あります。
PHPUnitでも、モックやスタブを適切に使わないことで、意図が伝わりにくい不明瞭なテストコードが生まれてしまいます。
このセッションでは、具体的な例を交えつつ、PHPUnitにおけるテストダブルの適切な使い分けについて話します。
プロダクトコードだけでなく、テストコードにおいても可読性は大事です。
良いテストコードを書くために、良いテストダブルの使い方を知っていきましょう!!
話すこと
・モックとスタブの違い(基本の部分)
・PHPUnitにおけるテストダブルの使い分け
・使い方が間違っているケース(具体例)
Tests as Documentationという考えがあります
自動化テストは、コードの動かし方と、どう動作するかを示す文書のようにある(べき)です
つまり、他者を意識して何かを伝えるのを助ける存在とも言えるでしょう
もっと言えば、受け取る側と伝える側がいる”Test as Communication"とも呼べそうです
例えば、プルリクエストを送る場面。レビュアーに「伝えるため」のテストになっていますか?
何を理解して欲しいか、どこを気にして欲しいか、そのために何を強調するか──
テストコードを「伝わりやすくする」ため気をつけている事を、 主観や好みや癖を盛り盛りで話します
Laravelでbladeを書く際に、 @csrf という「おまじない」を書いた経験が誰しもあるかと思います。
この @csrf は CSRF攻撃を防止するためのものですが、CSRF攻撃とは具体的に何で、@csrfを書くことでLaravelが裏でどのようにCSRF攻撃を防いでいるかを説明できるでしょうか?
このセッションでは、
についてお話しできればと思います。
現在時刻に関するテストの話題、よくありますよね。
ユニットテストでは現在時刻に関するテストも可能な設計にしているかと思いますが、
QA環境で、たとえばプロダクトマネージャーやその他企画職の様なエンジニア以外の方が、
未来の日時に始まるキャンペーンをテストしたい場合、どのようにされていますでしょうか?
DBのキャンペーン開始日時のデータをいじる?
→DBじゃなくてソースコードにハードコーディングされていたら?
ソースコードに書かれている開始日時を修正しちゃう?
→それもいいけど、間違えてデプロイしない?それに何度もやるのはめんどくさい。
など簡単な手段はありますが、デメリットもあります。
これらのデメリットを解消し、誰でも簡単に現在日時を変更して検証できるようにした(前半は現在時刻に関する一般的な設計テーマ、後半はSymfonyを使った実装アプローチについて)話をしたいと思います。
WordPress運用、苦労してませんか?
こういった、WordPress運用をサーバーで行うことの辛いところを解消する運用を編み出したチームがあります。ぼくたちです。
このLTでは、以下について実現できて運用している事例を紹介します。
Webサービスは、検索エンジンのクローラーから脆弱性を狙った攻撃Bot、さらには転売目的の在庫探索Botまで、様々なBotによるアクセスにさらされています。検索エンジンのクローラーはサイトへのアクセス増加というメリットをもたらしますが、その他のBotアクセスはサービスの安定性やセキュリティに深刻なデメリットを引き起こします。
このセッションでは、Pythonを利用した機械学習を用いて、これらのBotアクセスを効率的に判別し、効果的なアクセス制御を実現した事例についてご紹介します。特に、PHPで構築されたWebサービスやWordPressを運用している方にとっては、脆弱性を狙った攻撃からの防御が他人事ではないと感じていることでしょう。
実際のデータを元に、どのようにしてBotアクセスの特徴を捉え、機械学習モデルを用いてこれらのアクセスを分類・制御するかについて、具体的な方法論を紹介します。
ある程度複雑なWebアプリケーション機能を作るとき、ユニットテストを書くべきか、結合テスト(aka 機能テスト, FeatureTest, FunctionalTest)を書くべきか?
カンファレンスに参加する意識の高いPHPerの皆さんは「テストコードがあるだけでありがたい」は平成で卒業して、プロダクションコードだけでなくテストコードも保守しながら持続可能なアプリケーション開発を目指していることと思います。「このクラス、どうテスト書けばいいですかね?モックを使ったユニットテストでも書けるし、DBデータを使ってユニットテストすることもできるし、呼び出し元のコントローラに対するテストでも書けるんですが…」
最近、チームに新しくjoinしたメンバーと議論したのをきっかけに、私が自分なりに定義し直したテストコードの「要はバランス」についてお話しします。
ソフトウェアエンジニアには抽象化の能力が重要と言われます。
では実際に抽象化とはどのような能力なのでしょうか?
実際の事例を交えながら、抽象化を理解し、実務に活かせるようにします。
PHP Standards Recommendations 、通称 PSR と呼ばれる、 PHP エコシステムで共通のインターフェースを宣言し、それに準じて実装することで再利用性・可搬性を向上させる施策があります。
その中でも今回は PSR-15 に焦点を当てて、この PSR が 誰のために作られ、どうやって使っていくことが求められているのか をインターフェースから解説していきます。
handle
という 1 メソッドだけが宣言されたこのインターフェース、一体どう使えば良いのでしょうか? PSR-7 に批准していない Laravel(Symfony) ユーザーはどうこれをとらえれば良いのでしょうか?
PSR-15 批准フレームワークを 自作 して得た PSR との向き合い方をご紹介します。
初心者向けのセッションです。
対象:
• PHPをこれから始めたい方
• 学習中に壁にぶつかってしまった方
• ChatGPTの活用を知りたい方
ゴール:
ゼロから始める方にもわかりやすく、PHPがはじめられるようになります。
内容:
近年、AI技術の進化により、言語習得のハードルがぐっと下がりました。
このセッションでは、ChatGPTを使ってPHPを学ぶ効果的な方法を紹介します。
• ChatGPTを活用した効率的な学習方法
• PHPの基本的な概念と書き方の解説
• 簡単な開発環境のセットアップ方法
• ChatGPTを使ったコーディングのヒントとテクニック
• 実際に動くシンプルなプログラムの作成
ChatGPTを活用して、よりスムーズに、そして楽しくPHPの世界に飛び込んでみましょう。
結婚準備クチコミ情報サイト「Wedding Park」は今年でクチコミサービス開始から20周年を迎えたウェブサイト。
このレガシープロダクトでは、幾度もPHPで動くシステムのバージョンアップやシステムリプレイスのプロジェクトが生まれてきました。
・PHPのバージョンアップ
・Laravelフレームワークへのリプレイス
・オンプレサーバからAWSへの移行
・コンテナ化 など
システム運用者として定期的にアップデートしていきたい想いと、長期にわたる大規模プロジェクトとなり頻度高く実施ができない。そんな悩みとぶつかっていました。
その歴史の中で約10年、アプリケーションエンジニアとSRE、各視点で向き合って運用・開発してきた経験を基に、
・これまでのシステム改善の変遷と知見
・運用と開発視点でのプロダクトとの向き合い方
・新たな価値を継続的に提供し続けるための長期計画
をご紹介します。
PHP やプログラミングにまつわる内容をクイズ番組のような形態で早押しで答えていただきます。
回答者(またはチーム)はカンファレンス前に募集しておき,トーナメント形式で実施します。チームを組むのもあり,一人で答えるのもありの本格クイズ形式で進めます。
例えば以下のようなクイズに早押しで答えていただきます:
「PHP でファイルパスを指定して,ひと関数だけで読み込むには file_get_contents を用いますが,ファイルパスを指定してひと関数だけで書き込むには何の関数を使えばよいでしょうか?」
のような出題に対して「答え: file_put_contents」とどなたかが(もしくはチームが)答えられると正答数が加算されるような仕組みです。
PHP を書く上で、静的解析ツールは必需品となりました。コードを実行する前に型を解決し、問題を明らかにすることで、開発イテレーションを大きく向上することが可能です。
静的解析ツールはいくつかありますが、その中でも PHPStan は非常に強力なツールとして利用されています。その PHPStan で最も細かく解析してくれる level: max
を使うと、 mixed
型や array-shapes
を含め 全ての変数に型を明示する必要があります 。
このトークでは、自作 PSR-7 実装を通して、どのようにして level: max
な PHPStan で 型安全 に実装するか、そして その費用対効果がどれほどなのか を紹介します。
レベルマックスな PHP ユーザーは一体どうなるのか?解き明かします
心を込めて模倣をすれば、Composerと心は通うのか──
「composer require hoge/fuga
と打ったら、適切にパッケージが配置され、オートロード可能な状態になった」
を100分間で目指す企画です
composer require
で新規パッケージをインストールする、一連の流れ