tl:dr

このセッションでは、Laravelの上で、新原さんの独立したコアレイヤパターン、テスト駆動開発、 LarastanやPHP Insightsといった静的解析ツール、Circle CIを取り入れて、個人開発でも継続的かつ安定的にソフトウェアを進化させるための取り組みをしているという話をします。

概要

個人開発のウェブサイトでも企業のプロダクトと同じように、ユーザーの満足度を向上させるために日々進化させていかなければなりません。

しかし、個人開発では、平日の朝や晩、土日の予定のない日という限られた時間しか使えません（お金も出ません）。
このため、開発スピードを落とさないことは重要です。
開発スピードが早ければ早いほど、次の施策を考えたり、自分の余暇の時間を増やすことができるためです。

では、節約できる時間は何でしょうか。それは、新機能を開発する時間だけではなく、既存のコードを変更する時間、バグを修正する時間、毎回デプロイをする時間です。
継続的にソフトウェアを進化させるための種々のプラクティスを取り入れたら、開発における無駄な時間を減らし、新しいコードを怖がらずに追加できるようになったので、そのプラクティスを紹介します。

RDBはアプリケーションの心臓部です。たった1つのSQLがサービス全体に深刻な負荷を与えることも珍しくありません。

SQLを意識せずコードが書けるのはEloquentの大きなメリットですが、実際のSQLを書けない分だけトラブルシューティングは難しくなります。

意図せぬ負荷は避けたいが、普段はSQLを意識せずコードを書きたい。

この両立は可能でしょうか？データベースエンジニアの立場からお話しします。SQLの知識の有無は問わない内容です。

プッシュ通知の配信は、ReproやOneSignalといったサービスを利用する事が一般的です。
しかし、リミアではサーバ側の入稿及び配信システムを内製化しました。
内製化した理由、プッシュ通知の仕組み、開発したシステム、それを使った業務改善事例について説明します。
このセッションを聞く事で、プッシュ通知の仕組みや改善事例について把握できるだけでなく、静的型付言語が使われている場所にPHPを導入する参考事例を知る事ができます。

ステートレスなHTTPをステートフルに変えてくれる仕組みがセッションです。ユーザのログイン、リダイレクト後のエラーメッセージの表示、CSRF対策等、現代のウェブアプリケーションで多用されているセッションですが、セッションがどのように動いているかと聞かれた時に正しく答えられますか？
初心者に近いPHPerがセッションを多用すると、中堅クラスのエンジニアから「セッションは危ないから多用しないように」とアドバイスされることも多いと思いますが、それは何故でしょうか？

本トークでは、ウェブアプリケーションにおけるセッションについて、その正体を分かりやすく解説します。また、セッションの正体を知ることで、ウェブアプリケーションのアーキテクチャーに対してセッションが及ぼす影響についても解説します。セッションにまつわるアレコレを解説することで、初心者とベテランエンジニアの間に存在する知識と経験の差を少しでも埋めることが狙いです。

このトークでお話すること

• セッションの仕組み
• Laravelにおいて無意識に利用されているセッションの例
• Laravelが独自のセッション管理を行う理由
• セッションが本番アプリのアーキテクチャに与える影響

フルスタックWebフレームワークLaravelの最大の特徴はEloquent。
Eloquentを制するものがLaravelを制するといっても過言ではありません。

Laravel利用者同士であれば、Eloquent Modelをどう使うか、太りがちなロジックをどう整理するかなどなど、Eloquentの話だけで一日中語り尽くせることでしょう。

最近のカンファレンスのLaravel系のトークでは、Laravel利用者が成熟してきたせいか、アーキテクチャや設計論が目立ち始め、Eloquent Model自体への評価は下降気味だと感じています。
曰く、Eloquentはやんちゃが過ぎるのでリポジトリに閉じ込めるべきである、ORMの"Model"クラスとは別のPOPOのクラスをドメインモデルとして使うべきである云々。

本トークでお伝えしたいのは、我々が普段書いているEloquent Modelのコードと、カンファレンスで話される理想的な設計の話は地続きであり、決して雲の上の出来事ではないということ。コードの良し悪しはとあるアーキテクチャやパターンを取り入れるかどうかのゼロイチで決まるものではなく、その間にある無数のトレードオフに目を向けることが大事だということ。

目の前にある泥臭いLaravelアプリケーションのコードと付き合いながら、設計について考えていきましょう。

● お話しすること

• ActiveRecordとDataMapper
• ドメインモデルと永続化モデル
• リポジトリパターン
• ドメインモデルとしてのEloquent Model
• Eloquent Modelを分割統治するためのパターン集

● お話ししないこと

• クリーンアーキテクチャ
• ドメイン駆動設計

P.S. Laravel中〜上級者の皆様へ

リポジトリパターンやクリーンアーキテクチャは本当に必要ですか？
それらが利用される本当の目的を理解して利用していますか？
POPOが正義でしょうか？
Eloquentは力をセーブさせざるを得ない悪い子でしょうか？

本トークを通じて、Laravelを使い始めた頃に感じていたEloquentの万能感を、ぜひ思い出していただければと思います。

普段なにげなく使用しているフレームワークの中身、どのくらい知っていますか？
本セッションではLaravel Frameworkの中でも特徴的な実装をわかりやすく解説します。

ServiceCotainerやFacade(Real TIme Facade)、ミドルウェア、Eloquent…フレームワークの実装はなかなかに興味深いものだということ、フレームワークの実装を知ることでトラブルを未然に回避できるということ、PHPという言語の面白さを伝えることができればと思います。

みなさん、PHP で乱数を作成する際に何を使ってますか？それって本当に安全ですか？

PHP は乱数生成器をたくさん実装されていますが、いったいどれを使えばいいでしょう。
「rand()」「mt_rand()」「random_int()」「random_bytes()」「openssl_random_pseudo_bytes()」これらの違いを皆さんはご存知でしょうか。
そもそも乱数とは何か？安全な乱数とはどのような基準なのか？どのような実装なのか？といった、乱数に関する基礎知識の解説を交えながら、PHP における乱数生成アルゴリズムについて解説します。
みんなで PHP 実装における闇の片鱗に触れましょう。