皆さんはテスト環境をどのように用意していますか?
理想を言えば本番環境と同一の構成を用意してしまうのが安心です。
しかし、マネージドサービス多用の構成のインフラコストが馬鹿にならず、全部入りVMを使う構成に落ち着くことはありませんか?
実際、弊社にも全てを詰め込んだEC2一台で運用されるテスト環境が存在しており、
インフラコストの代わりに運用コストが高くなっているなと感じています。
本トークでは、コンテナやDBなどのマネージドサービスを使って運用コストを下げつつもインフラコストにも配慮した構成を模索します。
テスト環境だけでなく、小規模サービスや個人開発のインフラ構築の参考にもなれば幸いです。
● お話ししたいこと
● お話ししないこと
Webアプリケーションはどうして動くのでしょうか
ブラウザ等のクライアントから送信されたHTTPリクエストを契機に、
Webアプリケーションでは様々なレイヤーでの情報処理が行われます
今回はその情報処理の流れをLaravelを例に追うことで、
Webサーバー、Laravelアプリケーション、データーベースと
レイヤー毎で行われている処理と、そのレイヤー毎のつなぎ込み部分に迫ります。
HTTPヘッダーを含むHTTPリクエストの流れを追って、真にWebアプリケーションがどうして動くのかを知り、
必要な処理をどこに組み込むことが効果的なのかを知る一助になれば幸いです。
Webアプリケーションを運用する上で、監視の仕組みは欠かせません。
SREの文脈で特に重要性が高まるアプリケーション監視ですが、世の中には様々な監視サービスが存在します。
今回は特にAmazon CloudWatchをコアに据え、どの様にWebアプリケーションを監視する事が出来るのかを考察します。
AWS以外のオンプレミスも対象とした、提供するアプリケーションに対して
コストメリットも含めた監視サービスについてお話します。
フルサーバーレスな構成を取る場合、様々なクラウドサービスの知識に加え
実践的な利用方法が求められます
またAWS上でフルサーバーレスなアプリケーションを作成しようとしても、
AWS LambdaのネイティブランタイムにPHPはありません
フルサーバーレスの恩恵を受けたいが、その第一歩が難しい
その悩みをAWS Amplifyは解消してくれます
普段はPHPで実装するバックエンドをAWS Amplifyに任せることで、
React + GraphQLで作成するログイン付きのサンプルWebアプリケーションを作成する流れについてご説明します
具体的な手法をなぞることでフルサーバーレスなアプリケーションを作成手法を学びましょう
LaravelのORMであるEloquentは、Laravelの多彩な機能の中でも特に重要なものです。
しかし多機能で、とても大きなモジュールです。みなさんは十分に理解して使えているでしょうか?
関連するクラス・トレイトが主要なものだけでも10以上、Eloquent\Modelを継承したオブジェクトから使用できるpublicメソッドは、少なく見積もっても300以上と、巨大で複雑です。
素直にコードを読んで理解しようとすると、何日かかるかわかりません。
しかし大きくて複雑な問題も、小さく分割して、抽象化することで対処できます。
このセッションでは、Eloquentを使用してきた経験、公式ドキュメントの記述、実際にコードがどう分割されているか、どのようなタイプのメソッドがあるのかなどのあらゆる視点を駆使して、巨大なEloquentの全貌を解き明かしていきます。
現在、正規化という手法はDB設計においてよく知られている手法となっています。
しかし、現場では以下のようなテーブルを見かけることは珍しくありません。
・1 つのカラムに複数の値が入ったテーブル
・カラム数が多いまたは、1 つの情報変更で更新処理が多く必要なテーブル
・JOINすると期待通りの結果が得られないテーブル
これらは低次の正規化により一定解決できます。もちろん闇雲に分割すればいい訳ではなく、
正規化の概念を正しく理解した上で分割を行う必要があります。
そこで本セッションでは、リレーショナルデータモデルが集合論に立脚していることから、数学的背景に着目して第1〜第2正規化について紹介します。
具体的には、RDBの用語(候補キー・関数従属性・情報無損失分解・正規形)を適宜厳密に解説しつつ
実際の正規化の例を通して、PHPer が向かうべきテーブル分割の手法を持ち帰っていただきます。
CakePHP2とCakePHP4が混在する環境でPHP7.3→8.1にバージョンアップを行いました。
このトークでは、この環境におけるバージョンアップのアプローチと、バージョンアップの際に発生した問題点、
そして、それをどのように解決したかを話します。
主なトピック
・サーバー構成とサービス分割について
・CakePHPバージョンと、それに対応するPHPバージョン
・バージョンアップの前準備
・サーバーのコンテナ化、Immutable化
・リリースフローの変更
・M1 Mac等のArm環境でも動作する開発環境について
・PHP8.1バージョンアップ時に生じた問題と解決方法
・PHP8.1に対応していないCakePHP2に対するアプローチ
テスト書いてますか?
テストを書く理由と実際のテストコードを紹介する実践編に分け、TDD を3年間実践してきた経験に基づいてお話しします。
テストを書いたことのない方が、テストを書いてみたいと思ってもらえることを目指します。
サンプルコードは PHP + PHPUnit ですが、他言語でも通用する考え方を紹介します。
■ 概要
・なぜテストコードを書くのか
・レガシーコードとは、テストのないコード
・テストはコストが安いフィードバックループである
■ 実践編
・テストケースは日本語で書こう
・いろんな assertion を知ろう
・arrange / act / assertion のテストコード実装パターン
・set up / tear down を使って前処理/後処理をする
・dataProvider でテストをまとめる(ただし早すぎる抽象化に気をつけよう)
■ 発表内容
チーム開発に効果的なアジャイルのプラクティスとその実践例を紹介します。
■ 背景
「ゴールデンウィーク明けまでにお願い」と社内向けの機能開発を任されたとあるチーム。
チームは4月頭に組成されたばかりであり、この機能はビジネスの成長ドライバーになることを期待されている。
期間は根拠はない1ヶ月。
チームメンバーはプロダクトオーナー1名、エンジニアマネージャー1名、エンジニア6名。
不確実性に対処しつつ円滑にリリースを行うべく、アジャイルのプラクティスを実践して開発に立ち向かっている(プロポーザル執筆時点でまだ未リリース)。
確かに当初の予定よりは遅れている。しかし、チームの誰一人として疲弊していない上に偉い人からも「安心感がある」と好評価だ。
何がうまくいっているのか。3ヶ月間におけるチームの変遷を総括しつつ、開発を支えるアジャイルのプラクティスとその実践例を紹介します。
リモート化や、フリーランス、副業という新しい働き方が一般的になるにつれて、開発環境に要求される内容も変化してきていると思います
例えば PC のスペックや OS を選ばずに開発環境が構築出来る事や、リモートでも気軽に開発中の内容をチームにシェアして議論が出来る、といったような事があたりまえな要求になってきているのではないでしょうか
こういった課題を解決する一つの方法として弊社の Laravel の開発環境を例に GitHub の Codespace のセットアップや利用事例を解説します
Laravel sail を使っている方なら、一回は目にしたことがある Mailhog。他にも MailCatcher といったローカルでメール送信のテストをすることがあるのではないかと思います。
実際にこういった SMTP サーバーの役割を果たすものは使ったことがあるものの、どういう仕組みでメールのやり取りがなされているのか
興味がある方もいらっしゃるかと思います。
そこで、本トークでは SMTP サーバーとしてのプロトコルの解説から、PHP だけで SMTP サーバーを作るにはどうしたらよいのか、テクニックも含めて解説します。
ほぼエンジニアがいない状態からある程度の人数までスケールした組織で、コードの変化や Developer Experience がどのように
変化したのか、時系列で語られることはそうそう多くないです。採用から始まり、プロダクトを作っていく過程で、避けて通れないのが組織の成長です。
少ない人数では上手く機能していたのに、エンジニアが増えた途端、組織が機能しなくなったという話もよく耳にします。
そこで本トークでは、組織規模が大きくなるにつれて、実践した Developer Experience への取り組み、取り組んだ結果、どのように PHP で書かれたプロダクトに影響が及ぼされたのか、ノンフィクションでお話します。
何度も遭遇する PHP の「Allowed memory size of ...」。しかし、結局解決方法がわからず、最後には「ini_set('memory_limit', -1)」でその場を凌ぐという苦い経験をした方も多いのではないでしょうか。
PHP ではガベージコレクションもそれなりに発達しており、メモリを気にしないで書けるから良いと思っている人も少なからずいらっしゃると思います。
しかし、裏を返すと、メモリについてあまり考える機会がないとも言えます。PHP8 から弱参照といった機能も入り、メモリ管理に少しずつ関心が寄せられてきているのではないかなと思います。
そこで本トークでは、PHP でどのようにすれば省エネにメモリを使えるか、書き方のヒントまで含めてお話できればと思います。
Suica や PASMO をデバイスにタッチして値を取得する、そんな夢を PHP で叶えたいと思っていた PHPer も多いかと思います。
PHP7.4 から PHP FFI と呼ばれるものが導入され、その夢も今まで以上に叶えやすくなりました。Suica や PASMO は FeliCa と呼ばれる NFC の規格の 1 つです。実装方法は多岐に渡りますが、概ね libnfc と呼ばれるライブラリや libusb を使う方法などがあります。しかし、今までの PHP ではこのライブラリを呼び出すことさえ叶いませんでした。そこで、本セッションでは PHP7.4 から導入された PHP FFI を用いてどのように PHP で NFC リーダーを実装するのか、そして実際のデモを交えてトークできればと思います。
PHP 8.1 から Fibers が導入されました。それ以前の非同期処理といえば、Swoole などが筆頭になっていました。
非同期処理ライブラリが PHP にビルトインされるのは PHP に革命をもたらしたと言っても過言ではありません。
しかし、Fibers ではできないこと、Swoole でできることなど、実際には分かれています。
そこで、Fibers と Swoole の違いはなにか、それぞれの使い方を広く浅く本トークで解説します。
PHP に FFI が導入されてから、どういう用途で使えばよいか悩んでいる PHPer も多いかと思います。
PHP FFI を介したモジュールの呼び出し方から、自作 の C/C++ のモジュールの作成から呼び出し方、
そして libusb と呼ばれるモジュールで USB で接続された機器の一覧を取得する方法など、どのように FFI を活用していけばよいのかを本トークで解説します。
重たい処理をキューに任せることで、早めにレスポンスを返すことが可能です。しかし、Laravel 標準のキューサーバーの処理速度にはある一定の限界があります。
弊社では、1 回あたり数十秒かかるような処理をキューに任せているのですが、キューが積まれすぎて処理しきれず破棄されるといった事象が起こっていました。
Laravel には Laravel Horizon と呼ばれる並行並列でキューを処理ができるライブラリがあるのですが Redis のみのサポートで、弊社では Amazon SQS を使用しているため、導入には至りませんでした。そこで、Amazon SQS 向けに Laravel のキューサーバーを自前で実装し直し、処理速度を 4 倍に向上させました。どのように処理速度を高めるのか、そのテクニックのご紹介と実際のプロダクションへの投入、得られたパフォーマンスなどを本トークでお話します。
symfony/pantherはブラウザテストやWebスクレイピングを行うためのライブラリです。
Symfonyに限らずあらゆるPHPプロジェクトに統合して利用することができます。
ところで、少し前にWordleというゲームが大流行しました。
WordleはWebベースのゲームなので、ヘッドレスブラウザを使えばプログラムで機械的に解くことが可能です。
というわけで、今回はsymfony/pantherを使ってWordleを解くプログラムを実際に作ってみます。
このトークでは、その実装内容を説明しつつ、symfony/pantherの基本的な使い方もご紹介できればと思います。
API Platformは、Symfony + DoctrineをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュート(アノテーション)を1行追加するだけで一瞬でREST APIを生成できてしまう優れもので、Symfonyのエコシステムにおいてはすでに決定版と言える存在となっています。
このトークでは、API Platformの導入方法から、Data Provider・カスタムコントローラ・Data Persisterといった重要な基本機能の概要までを、実際に動作するデモをお見せしながら一通りご紹介できればと思います。
皆さんにAPI Platformの概要を知っていただき、少しでも興味を持っていただければ幸いです!