Laravel.osaka 2016 に参加した記録

リンク

http://php-jp.github.io/laravel-osaka-2016/
http://laravel.connpass.com/event/41141/

Passportではじめる OAuth2

LaravelにはPassportというOAuthを使用することが出来るパッケージが存在する

OAuth2 はクライアントの実装が楽！

artisan vendor;publish resoures/view/...にbladeが吐出されるので、それを編集してあげればカスタマイズが可能

なぜPassport をつかうのか

こんな時に嬉しい

• 表はSPA 裏はAPI(ドメイン分離)の場合
• モバイルアプリのバックエンドにAPIを使う
• サードパーティがクライアントアプリを作れるようにしたい
• SSOをしたいとき

Laravelにおける後悔しないためのアプリケーション設計 @localdisk

laravelリファレンス好評発売中！

今日の方針

シンプルさを保つように

アジェンダ

• Facadeを控えてみる
• Named Routes
• FormRequest
• ControllerでEloquentのメソッドチェインを禁止
• Repository Pattern

Facadeを控えてみる

静的メソッドのように使えるので、どこからでも使える。Viewの中でも使える。
=> 結果、クラスの責務・影響範囲が大きくなる

解決策

• DIを使おう
• なるべく Contract を使おう

なぜ？
Facade を使う代わりに DI を使用すると、メソッドの引数に使用するクラスが並ぶので「やばい。」気づく。
=> リファクタリングが出来る

NamedRoute

Routeに名前を付けることが出来る
=>route('osaka')でURLを取得できる
=>URLが変わっても安心

FormRequest

Validation の変遷
別クラスでバリデーションを定義して、Controllerにはバリデーションがかかった結果が送られるという前提を作って実装する

ControllerでEloquentのメソッドチェインを禁止

Model bindingは /url/{date} の {}内と関数の引数名が同じだと発生する

Controllerでメソッドチェインをすると漏れが起きやすいので、Modelに閉じ込める
=>再利用性も上がり、クラスに生やしたメソッドを呼ぶだけで済む

Repository Pattern

• Eloquentは User::find のように静的に呼べるが、Facadeではない
• よって、shouildRecieveというメソッドは存在しない
• EloquentはDBに依存しているので、ユニットテストが書きにくい

Repository Pattern の作り方

インターフェイスを作成
↓
インターフェースをクラスで実装
↓
後はそのクラスをControllerでインジェクションする

Laravel でアプリケーションを開発し Heroku で公開するまでの一部始終 @ 大村 創太郎

1hour で Massage Boardをつくる！

• Homestead(簡単にLalavel を使えるようになるVagrantBox)をつかう（インストールから始める…！）

環境構築

• git clone で HomeStead は手に入る！
• homestead では yamlファイルに設定を記述する

vagrantの起動

• prestissimo を入れることで composer を素早くさせる
• laravel プロジェクトを作成する
• 15分でLaravelのあの画面がお目見え！！

開発を始める前におすすめすること

composer require laravel-ide-helper 入れよう
composer require dbal

開発開始！

• URLマッピング
• 生HTMLコーディングでForm作成
• メッセージ登録用POSTメソッド作成

csrf_field()メソッドの利用によってアクセストークンが準備されるので、クロスサイトリクエストフォージェリの対策が簡単に出来る

• DBの作成
  artisan make:model -m Message でモデルとマイグレーションファイルも同時に作ってくれる

• DBへのデータの追加！

• viewに値を渡す（view の第二引数に変数を指定する）

40分で動くものが完成！

Heroku に登録！

• 2分ぐらいでHerokuへの登録・受け取り側HerokuAppが完成！

Heroku にデプロイ！

• GitHubとコネクトして、プッシュされているものをDownLoad/Install してくれる！
• Postgress とコネクトするアドオンがあるので、それを使用！
• それに伴ってHeroku側にPostgress用の設定（環境変数の設定）を行う

laravel ではView内で使われる関数に対してきちんとセキュリティ処理されたものを表示してくれる！

=> これをしたくない場合は、 {{!! /* code */!!}}でセキュリティ処理しないようにもできる

時間の許す限りリファクタリング

• Routeに書いたロジックをControllerに切り出し
• 文字なしで登録をできないようにバリデート

DDDパターンを活用したLaravelアプリケーション開発 @ １✕１株式会社 新原 雅司

対象システム・ユースケース

ECサイトでカートに入れるというユースケース

DDD (Domain Driven Design) って？

ドメインにフォーカスした設計・開発手法

ドメインとは？

• システムの対象領域・解決する問題領域
• 業務システムであれば、対象のビジネスがドメインに当てはまる
• ソースコード管理システムであれば、ソフトウェア開発がドメインに当てはまる
• セッション内ではECサイトがドメインに当てはまる

ユビキタス言語（ドメインに対して使われる一定の言語・用語のこと）

• ドメイン用語辞書（用語の定義を文書化したもの）
• プロジェクトチーム内でも同じ言葉を利用（非エンジニアも同様に）
• その言葉をコードでも利用する（名前空間やクラス名、メソッドなど）

定義内で数値の定義も行う

レイヤードアーキテクチャ

• システムをレイヤ（層）に分割する
• レイヤは自信の役割をになう　
• レイヤ感で強調して処理を行う
• レイヤ間の流れは一方通行

DDD で定義されているアーキテクチャ

• UI
• Application
• Domain
• Infrastructure

UI

ユーザ（連携システムも含む）とシステムの接点
HTTP, HTML, JSON, stdIn, StdOut, ビュー, Request, Response

ディレクトリ構造

• appのしたではなくpackages というディレクトリを作って自分の実装を置いていく
  なぜ？
  => フレームワークにはサポートしてもらうだけで、必要なところだけフレームワークを利用するため, Laravelのバージョンが変わってディレクトリ構造が変わっても、影響範囲が少ない

Domain レイヤ

• システムのドメインを実装するレイヤ
• ドメイン以外の関心ごとは含めない
  • HTTP, DB, キャッシュなど
• Prain Old PHP Object (POPO)で実装し、フレームワークからは独立する

=> Facade やヘルパー関数も使わない

• モデル、サービス、イベントなど

エンティティ

• ドメインモデルの実装
• Eloquent を継承しない（ドメインの中では継承してもOK！）
• 同一性はIDで判別

ValueObject

• 価格や日付などのプリミティブな値を示す
• 同一性は属性で判別
• 値に対する成約や振る舞い（演算）を実装

ドメインが反映されていないコードを書いてしまう

ValueObject を作成し、エンティティでは、intなどではなく、そのクラスを利用する
=> それによって、ソースコードにドメインが反映され、ソースコードからドメインを確認することが出来る。

ValueObject のポイント

ユビキタス絵言語をコードで実現
=> コードを見れば使用がわかる
メソッドで定義した演算しかできない
=> 間違いを減らせる
汎用型ではなく、特化型で
=> 「数字」ではなく「商品価格」
凝集度が上がり、扱いやすい、テストの容易性

メソッドをはやして条件分岐の判定を実装する

Domain レイヤのまとめ

• フレームワークから独立してPOPOで実装
• Collection などドメインを実現する範囲ならOK
• ValueObject でドメイン特化の方を作り、ユビキタス言語に則った実装する

Infrastructure レイヤ

• データストア（DB）やメール送信、外部API連携など、一般的な技術機能を提供するレイヤ
• リポジトリ、キャッシュ、APIクライアントなど

リポジトリ

• モデルとデータストアの間に介在し、分離する
• データストアからのモデルの取得、保存操作をインターフェイスにして定義
• データストアに対してインターフェイスを実装する

ドメインレイヤーにInterFaceを用意して、インフラストラクチャレイヤにデータストアと接続するクラスを実装する

リポジトリ + Eloquent

Eloquent を　Pwesistence Model として使う
インフラストラクチャレイヤのリポジトリの実装に閉じ込めてしまう
他レイヤで Eloquent は基本的に使わない（フレームワークが使う場合は仕方ない）

アプリケーションレイヤ

• システムのコントロールを担うレイヤ
• ユースケースの流れをつくり、具体的な処理はドメインやインフラストラクチャに移譲
• Route/Controller etc...

Controller で行うバリデーション

コントローラ内のバリデーションはビジネスルールのバリデーションは掛けず、型があっているか・値の範囲・必須が入力されているか程度のざっくりとしたバリデーションを行えば良い

アプリケーションレイヤのまとめ

アプリケーションレイヤで必要な情報はコントロールしている動きだけを知れればよい！

まとめ

• ドメインレイヤが主。それ以外は従
  • ドメインレイヤこそがアプリケーション！
  • 変化がはやいLaravelだからこそ！
• ドメインに特化した実装（とにかくValueObjectを作る！ぐらいの意識で）
• Laravelは自由度の高いフレームワーク
• 設計に関する知見などをどんどん共有しよう

Laravel でアクセスコントロールを簡単に実装する話 @ 増永 玲

Auth とは

• Authentication 認証 => 当人であることを確認して条件を与える
• Authorization 認可 => 与えられた物によって条件を与える

クロージャ

コールバック内の関数のこと

\Gate::allow('{アビリティ名}', {何に対してなのか}) を記述することで簡単にがアクセスコントロールできる
アピりティの中では true/false を返す

もっと簡単に

authorize('{アビリティ名}', {何に対してなのか})

Vue.js + Lumenで学ぶWebAPI駆動プロダクト @ cloudpack 高橋 慎一

2014 年に設計したアーキテクチャ

• DB
• Webserver
• ビジネスモデル（処理部分）

2016 年に設計したアーキテクチャ

• DB
• APIServer [前バージョンのWebserver] （EntryPoint・サービス（アプリケーション）層）
• ビジネスモデル（処理部分・ドメイン層）
• 認証サーバ
• Webserver（フロントエンドでの実装）

ビジネスモデルの部分とAPIServer、WebServerの３つをAPIでつなぐ形。
いわゆる、MicroService

なぜ MicroService を使ったのか

• 部分変更に強い
  • DBはRDBがいい！
  • ミドルウェアのバージョンアップが…！
• 必要な部分だけサイズ（規模）を変更することができるので、スケーラビリティが高い

Lumen をつかって API サーバを実装する

なぜ Lumen ?

Lumen は Laravel よりも小さい、Laravel Like なフレームワーク

• Laravel ほど Fat なものでもない
• 情報が多い
• ARN(Amazon Resource Name)とルーティングの相性が良い
• ミドルウェアを使って認証が出来る
• AWS SDK を使ってDevice Farmと通信が出来る

Vue.jsを使ってWebServer（フロントサイド）を実装する

なぜ Vue.js ？

• スモールスタート（少ない学習コストで学習を始めることが出来る）
• エコシステムが発達している
  • Router関係 (vue-router)
  • API通信関係 (vue-resource)
• シンプルである

まとめ

• Vue.js + Lumen で始めることで、やりたいことだけ覚えて作ることが出来る
  • 短期間で物を作るには最高の組み合わせ
  • モダンに作れた（ミドルウェアがあるので認証楽だった！）
  • わかりやすい形で MicroService を始めれた！
• MicroService を使うことで、インターフェースが決まっているので、バージョンアップに耐えうる
• I/OのJSONを見ているだけでテストするだけで良いのでSeleniumテストとかしなくていい分楽
• わからないこととは毎日格闘している。
  • セキュリティ
  • 非同期
  • テスト

単一のサービスだとまだMicroserviceは早かったかも…。とはいえ、今後長く運用していく上で後でメリットになると思う。

また、「MicroServiceでやってみる」というと割と突かれないので、便利な言葉だった！

Laravel アプリケーションとテスト 株式会社 chatbox 後藤 知宏

PHPでデバッグするときの方法として

• 画面に出力する派
  • var_dump(), dd() をどこに書いたかわからなくなる…
  • JSON APIだったり、リダイレクトするやつだと困る…
  • echo したものがどこかしらに残ってしまうパターン
• ファイルに出力する派
  • log に出力するので、logが汚れてしまう…

=> もっと手軽にデバッグしたい！

PHP7 の機能を使ってデバッグ

• PHP7 から引数も戻り値もどこでも方宣言することが出来るので、エラーを見つけやすくなる
• PHP7 の assert を使って検証する
  • assert は本番では実行されないので、パフォーマンスには影響しない。
  • ※しかし、実行されないため、条件文などでは使ってはいけない

Laravel の機能を使ってデバッグ

Laravel Artisan Command による、CLI デバッグ

CLI でユニットテストのようにデバッグすることが出来る。

基本的な機能をartisan command に登録しておいて、デバッグを行う。
=> OKなら、Controllerなどと連携させるようにする形

デバッグコマンドを作っておいて何が嬉しいか

• CLI から主要な機能を叩けるようになる
• 煩雑なユースケースで利用できるため、ヘルパーにもなる
• xdebug によるデバッグでステップ実行がしやすくなる（？）

PHPUnit によるテスト

PHPUnit って？

• 書いたコードを検証することが出来る
• phpunit.xml で構成を設定する
• Laravel には標準で入っている
• DBなどへの問い合わせは実際に行われるので注意
• 関数の結果をテストすることが主
• 画面の検証も可能(HTML, JSON, HTTPヘッダの中身, ステータスコード)
• テスト用のコードとして別の場所に書くので、本番コードを汚さない
• コードファイルを再実行することができるので、便利である！

テストコードを書く利点

• 規模が大きくなっても使うことが出来る
• テストに則ったコードを書くので、リファクタリングがしやすい

テストを書くのに不向きなパターン

• 実行結果が変わってしまうパターン
  • DB
  • 日付
  • セッション などに依存するパターン
• 期待が変わるパターン
  • 機能の仕様が頻繁に変わるパターン

テスタビリティを考える

• テストしやすいコード = 良いコード（可読性・機能分割がされている）
• 機能分割したコードを書くことが出来る
• DIを使ったコンポーネント注入を意識できる
• ミドルウェアやリポジトリパターンによる、分割するメリットがわかる

継続的にテストするために

自動テストの導入を行う
=>GitHubと連携させることによって、そのlog時点のコードが動くことを確証することが出来る！

テストを書くための心意気っぽいもの

• テストカバレージ（網羅性）をあまり考え過ぎないように
• 綺麗なテストコードよりも、まずは動かしてテストすることを出来るかどうかが重要