ここ数年、Laravelの利用者は大幅に増えました。
Laravelにはたくさんの便利な機能がありますが、その機能はどのように動いているか知っていますか?
本セッションではLaravelのコードの中で私がとくに面白い!と思ったものを(なるべく)わかりやすく解説します。
ここ数年、フロントエンド開発がリッチになるとともに、PHP界でもシングルページアプリケーション向けAPIの開発が多くなっていると思います。
そんな中、一般的な解説書や解説記事に従ってAPI実装を始めると課題にぶつかることになります。
たとえば、
アプリケーションのモニタリングしていますか?
デプロイした後のパフォーマンスチェックしてますか?
障害が起きてから監視ツールを眺めていませんか?
BASEでは最近、PHPで書かれているプリケーションの監視のためにNewRelicを本格的に導入しました。
NewRelicはAPMの印象が非常に強いですが他にも数多くのソリューションが存在します。
それらを使って自分達のオブザーバビリティプラットフォームを作りプロアクティブにアプリケーションをモニタリングしていくことができます。
APMに始まりNewRelic logsによるlog収集、Browserによるフロントエンドパフォーマンス監視、InfrastructureによるAWS監視、Syntheticsによる一歩進んだ外形監視。
そしてそれらの監視をNRQLというクエリ言語と組み合わせてダッシュボードにまとめて統合監視プラットフォームの構築を実現していきましょう。
Track ID: Track2-1-A
Discord Channel: #track2-1-a-base
Laravelで運用しているサービスをNuxt.jsにリプレイスした(している)状況を共有したいと思います。
Laravelで使われているロジックはそのままに、LaravelをREST APIとして稼働させてNuxt.jsでフロントエンドを構築しています。
サービスを無停止で移行する方法やインフラアーキテクチャ、苦労していることなどを共有して似たようなことを検討している人の助けになればと思います。
Track ID: Track4-1-A
Discord Channel: #track4-1-a-laravel-to-nuxt
【概要】
弁護士ドットコムでも、半年くらい前にPHPStan静的解析をはじめました。
徐々に対象ファイルを増やし、現在では2000超のファイルをスキャンしています。
level0(不明なclass、関数の参照などの基本的なチェック)から段階的に厳しくして、level2(未知の全ての関数のチェック、PHPDocの検証)に上がります。
レガシープロジェクトにありがちな名前空間がない、PHPDocがないといった問題を、nikic/PHP-Parser(https://github.com/nikic/PHP-Parser)を武器に乗り越えてきました。
PHPDocで補いきれない部分は、自作のYii1フレームワーク用のPHPStan拡張で解析しています。
レガシープロジェクトで、静的解析を進めてきた方法を話します。
Track ID: Track2-1-B
Discord Channel: #track2-1-b-bengo4
「Laravel開発者の負担・工数を減らす」を掲げて、約10ヶ月前にリリースした「 LaravelDB.com 」。誰もが無料でお使いいただけます。
ER図を書けばそのとおりのMigration(最新バージョンではテーブル設計どおりのValidationも生成します)ファイルが生成されます。ER図は保存が可能なので、何度でもER図を呼び出して変更加えたり、コピーして別のプロジェクトを作成することも可能です。このツールの勘所を端的に解説する予定です。操作方法を知って少しでも楽に開発ができるように、少しでもLaravel開発者の皆さんの手助けになれば幸いです。
Track ID: Track4-1-B
Discord Channel: #track4-1-b-laraveldb-com
年末から年始にかけて開始予定のウェブ・セキュリティ実務知識試験(徳丸実務試験)とPHP8上級試験の解説をいたします。徳丸実務試験に合格して徳丸皆伝ステッカーをもらおう。稟議に使えるPHP市場データも解説。
Track ID: Track2-2-A
Discord Channel: #track2-2-a-tokumaru-exam
Google Cloud Platform(GCP)ではPHPを動かす環境がたくさんあります。
Google App Engine(GAE)だけでも3パターンあり、
他にもGoogle Compute Engine(GCE),、Google Kubernetes Engine(GKE)、Cloud Run があります。
この発表では、それぞれの環境でやれること、メリットデメリットについてお伝えします。
また、どういう考えで環境を選ぶかというプロセスを実体験を交えながら、ご紹介します。
Track ID: Track3-2-A
Discord Channel: #track3-2-a-gcp
新卒3年目が新チームに入って皆から良くなったと感謝されることが増えました。
何が良かったの分からなかったので、改めて自己分析した話をします。
明日からできる簡単なことなので、お話きいていいなぁと思ったら是非実践してください!
Track ID: Track2-2-B
Discord Channel: #track2-2-b-hamee
コンテナネイティブ時代に突入した昨今、PHPer の皆さんはコンテナ化は済ませましたか?
Chatwork 株式会社では2020年に PHP アプリケーションをコンテナオーケストレーションツールのデファクトスタンダードである Kubernetes に置き換えました。
そこで、これからコンテナ化を行おうと考えている PHPer の方々向けに
など、Chatwork の事例を元に解説します。
Track ID: Track3-2-B
Discord Channel: #track3-2-b-kubernetes
皆さんはテストを書いていますか?
テスト駆動開発をしていますか?
テスト駆動開発と言っても、どの部品の単位でテストを書けば良いか悩む方も多いのではないでしょうか。
テストを書く上ではソフトウェア設計への配慮が欠かせません。
ソフトウェア設計の大切さ、テスト駆動開発で単体テストを書く利点について理解を深め、その後にオニオンアーキテクチャを採用したソフトウェアでテスト駆動を行う手順を語っていきます。
当セッションでは下記のような話をする予定です。
・なぜテストを書く上でソフトウェア設計が大切なのか
・単体テストを書く利点
・オニオンアーキテクチャの解説
・オニオンアーキテクチャでTDDを行う手順
※アーキテクチャは触りだけ説明し、メインはテストの話になります
Track ID: Track4-3-A
Discord Channel: #track4-3-a-laravel-onion
PHP7でPreload, PHP8でJITと、PHPを高速化する仕組みが次々と導入されてきています。ベンチマークや解説記事などでどれくらいパフォーマンスが向上するのかをご覧になった方も多いかと思います。
しかし、一体どうして速くなるのか、どうのような仕組みなのか?Preloadとは何か、JITとは何をするものなのか、皆さんは答えられますか?
本トークではPHP8のソースコードレベルから、PreloadやJITの正体について、順を追って分かりやすく解説します。モダンなPHPが実行時にどのような動きをするのか、少し分かるようになってくれたら嬉しいです。
このトークでお話すること
Track ID: Track5-3-A
Discord Channel: #track5-3-a-preload-jit
テストピラミッドとは、Mike Cohn氏が提唱した各層のテストコードの比率や費用対効果を表したものです。
テストピラミッドでは「UIテストを薄く、ユニットテストを厚くした状態」が理想となっていますが、各層のテストコードを実装していく中でどのように意識すれば良いのでしょうか?
そこで、実際のPHP製システムにE2Eテスト、featureテスト、ユニットテスト等を実装する流れを例にして、テストピラミッドを意識したテストコード実装戦略について解説していきます。
どのような題材にするかは未定ですが、「過去にLaravel公式ドキュメントにあったチュートリアルのシステム(https://laravel.com/docs/5.1/quickstart-intermediate)を、Laravel8.x / PHP8.0にバージョンアップする」を題材にする予定です。
Track ID: Track4-3-B
Discord Channel: #track4-3-b-test-pyramid
「銀の弾丸はない」
ではPHP8は私達に何をもたらしてくれるのか。
私達はIikanjini Speed Up Contest、通称ISUCONの予選にPHPで挑戦しました。
結果は残念ながら468チーム中46位とあと一歩で本戦への切符を勝ち取る事が出来ませんでした。
実はどうしてもPHPでISUCON 本戦へ出場したい、その想いからPHP 8.0.0 Betaの投入を迷っていましたが
最終的に使うことなく敗退しました。そこに少なからず心残りはあります。
そんな中、先日PHP 8.0.0 Release Candidate 1が発表されました。
来年こそ、大手を振って導入できる事でしょう。
ISUCON は総合力の勝負です。
PHP8が銀の弾丸になることは無いのかもしれません。
しかし、私達PHPerはPHP8に壮大な夢を見らざるを得ません。
そこで私はPHP8のパフォーマンスに絞った内容調査を行う事にしました。
JITなどパフォーマンスに関して多大なる期待が寄せられているPHP8は、
私達をISUCON本戦の扉へ導く鍵となるかを検証してその成果をお話します。
今年、PHPを使ってISUCON 本戦へ進んだチームはただ1チーム
そのチームに続き、来年こそ私達PHPerの手でISUCON本戦への扉を開きましょう
■想定する聴講者
- PHP8のパフォーマンスに興味がある方
- PHP8のベンチマークに興味のある方
- 来年こそPHPでISUCON 本戦への進む心意気のある方
■お話しないこと
- パフォーマンス以外の話
- PHPのgRPC利用について
Track ID: Track5-3-B
Discord Channel: #track5-3-b-isucon
昨年のPHP Conference Japanにて、「Composerがどんな課題を取り扱い、それをコード上でどう表現しているのか」という発表をさせていただきました。
そして今、2016年04月のリリース以来、Composerは初めてのメジャーVersion Upに向けて準備が進んでいます。
(そう、”Re:born”ですね!)
昨今のPHPの進化を語る上で欠かせない存在となったComposerは、数年間の時を経てどんな進化をする(した)のでしょうか?
「どんな機能が増えて」「どんな改修が行われて」「それはどんなコードで実現しているのか」、興味がありませんか。
本セッションでは、主要な機能の紹介を、内部実装の”見どころ”を交えながら行います。
Track ID: Track2-4-A
Discord Channel: #track2-4-a-composer2
30年以上前に作られたDNSの仕組みが今もなお同じように動作し、私たちのインターネットを支えている。2020年、令和の時代に熱いDNSの話をして、インターネットの基礎を支える技術に興味を持ってもらいたい。
DNSレジストラの脆弱性によりドメインハイジャック事件が起こりました。この事象を防ぐのは難しく、いかに早く改ざんを検知するかにかかっています。
そこでDNSのネームサーバ情報を定期的にチェックして改ざんを検知し、通知するツールを作成してOSSで公開しました。
https://github.com/ichikaway/nschecker
本セッションでは、DNS改ざんによるドメインハイジャック、DNSの基本的な仕組み、検知方法、キャッシュとの戦いを紹介し、DNSプロトコルの実装を解説します。
基本的にDNSパケットはUDP 512バイトでやりとりされ、その制約から1bit単位で意味を持つようになっています。この意味を解説しながら、先人たちが1ビットまで大切にしてきた想い、考え抜かれた仕組みを紹介します。
普段の開発では知らなくても動いているDNSですが、DNSキャッシュや権威サーバのツリー構成など知っておくとトラブルシューティングやサイト移転時に役立ったりします。
Track ID: Track3-4-A
Discord Channel: #track3-4-a-dns-packet
昨年、最低限の機能でリリースとなった新サービス。
今も開発が続いているのですが、機能追加をリリースするたびに何かしらトラブルが発生してしまい、切り戻して終わる、ということが頻発していました。
この状況をなんとかしようと思い、足りてない施策をいくつか始めていきました。
Unit Test の自動化、PSR-4 チェック、そして、Laravel Dusk での Browser Test。
このセッションでは、開発から本番へ進む際にめぐりあった数々のトラブルをどう乗り越えて来たのか、と、
量産体制に入ることができている Laravel Dusk の Test 整備方法の一例を、デモを交えてご紹介できればと思います。
Track ID: Track4-4-A
Discord Channel: #track4-4-a-laravel-dusk
PHP 8 の新機能のふるまいを、php内部のテストコードを通じて、理解する時間を提供します。
PHP 8 がもうじきリリースされる昨今で、 PHP 8 についての新機能についての関心も高まってきました。さまざまな新機能の抑え方がありますが、ひとつが、テストコードを通じて対象システムを理解する方法です。
phptというものがあります。これは、 PHP 内部コード、つまり php-src の自動テストスクリプトです。
ここには、PHP という言語自体の comitter たちがどういう振る舞いを PHP に与えたのか、それがレアケースのユースケースも含めて記述されています。
テストコードを書く皆様であれば、 Test as Document 、仕様を伝えるドキュメントとしてのテスト、を自身が運用するアプリケーションに対して書きますよね。phpt は PHP 8 の新機能に対するテストコードも含んでいます。
コードの読み手が、テストコードを通じて、 PHP 自体の振る舞いを理解する。phpt に記述されたコードを通して、次の2つを学びましょう。
具体的には、PHP 8 の新機能を題材にします。想定しているお品書きは以下です。
※ もし、時間が許せば、上記の機能を実現するために、PHP内部の zend_compiler などにどういう変更があったか、まで軽く紹介します
Track ID: Track5-4-A
Discord Channel: #track5-4-a-phpt
「特定日時を過ぎたら実行される分岐処理を書こう」
このようなロジックを実装した経験が皆さんにもあると思います。
PHPに限らず、時間が絡む処理を書く場面は多いです。しかし、「安全」な実装を「早く」作れる人は意外と少ないのではないでしょうか?
「PHP 日付比較」で毎回検索するのは手間ですし、アンチパターンを踏み抜いてしまうリスクすらあります。
2020年の歳の瀬に日付の扱いに習熟し、PHPをより上手く安全に使いこなしていきましょう。
※PHPの標準実装やライブラリの話がメインにはなりますが、フレームワークを取り巻く状況についても触れる予定です。
Track ID: Track2-4-B
Discord Channel: #track2-4-b-phpdatetime
皆さんは普段DIコンテナを使っていますか?DIコンテナはそのメリットとデメリットを理解し、正しく使いこなせばソフトウェア開発の効率を高めてくれる非常に強力な仕組みです。
しかし、よく分からず使っていると却って、それっぽいだけでメリットを享受出来ていないソフトウェアが出来てしまう可能性もあります。
本セッションでは、CakePHPに新たに搭載されるDIコンテナの仕組みをもとに、そもそもDIとは何なのか?その上でDIコンテナとは何なのか?を紹介し、DIコンテナの導入によってもたらされる効能についてお話させていただきます。
また、これまで何故CakePHPがDIコンテナの仕組みを用意していなかったのか、何故このタイミングでDIコンテナが導入されることになったのかについても読み解いていきたいと考えています。
Track ID: Track3-4-B
Discord Channel: #track3-4-b-cackephp-di