フェイクニュース書き放題

近年フェイクニュースの問題は世間を騒がす対象になっていなすが。いまだにそのいい解決方法が出てきていません。

そこで、私は誰でもフェイクニュースを書き込めるプラットフォームを作る
という解決方法を見つけ出しました。

誰でもフェイクニュースを書き込めるということでツイッターやfacebookに書き込まれる
いたずらが原因のフェイクニュースは減少させられると見込んでおります。

登録方法

まずフェイクを投稿するにはサイトに登録しなければなりません
こちらのURLですhttp://fakebook.xsrv.jp/
下の画像の「新規登録」という項目をクリックしていただくと必要事項の
入力フォームに飛びますので、必要な物を入力してください。

ログインの場合はうえの画像を参考に新規登録の際に入力した
メールアドレスとパスワードを入力して頂ければログインできます。
次からログインを省略のチェックボックスにチェックを入れれば
5年間ログインしなくても使い続けられます

登録をせずに記事を読むだけなら読むだけならこちらをクリックしてください

主な機能

1.フェイクニュース投稿
2.記事の検索
3.フォロー機能
4.記事に対するコメント

１．フェイクニュース投稿

画像の右にあるフェイクするのボタンを押すと、記事作成フォームに飛びます。

そこでタイトル、フェイクニュースの内容、画像の選択をすればフェイクニュースは完成です。
次に確認画面にうつりそこで完了すれば最新のトレンドとして投稿が追加されます。

２．記事の検索

この検索窓に好きなワードを入力するとそれに関連したフェイクニュース
が読めます。

３．フォロー機能

ユーザー名のURLをクリックしてユーザープロフィールに移動すると以下の画面が
表示されます。「フォロー＋」と書かれたボタンを押すとそのユーザーをフォロー
することができます。

フォローしたユーザーは、自分の名前をクリックして出てくる欄の「フォロー」という項目
をクリックすればフォローしたユーザーとフォロワーの一覧が見られます。

上の写真の友達の投稿という項目をクリックするとフォローしたユーザーとフォロワーの投稿
が見られます。

４．記事に対するコメント

記事を読む画面の一番下側にコメント入力フォームがあります。
そこから自分のコメントを書き込めることができます。

以上がFakeNewsの機能及び使い方の説明でした。

フェイクニュース書き放題

近年フェイクニュースの問題は世間を騒がす対象になっていなすが。いまだにそのいい解決方法が出てきていません。

そこで、私は誰でもフェイクニュースを書き込めるプラットフォームを作る
という解決方法を見つけ出しました。

誰でもフェイクニュースを書き込めるということでツイッターやfacebookに書き込まれる
いたずらが原因のフェイクニュースは減少させられると見込んでおります。

登録方法

まずフェイクを投稿するにはサイトに登録しなければなりません
こちらのURLですhttp://fakebook.xsrv.jp/
下の画像の「新規登録」という項目をクリックしていただくと必要事項の
入力フォームに飛びますので、必要な物を入力してください。

ログインの場合はうえの画像を参考に新規登録の際に入力した
メールアドレスとパスワードを入力して頂ければログインできます。
次からログインを省略のチェックボックスにチェックを入れれば
5年間ログインしなくても使い続けられます

登録をせずに記事を読むだけなら読むだけならこちらをクリックしてください

主な機能

1.フェイクニュース投稿
2.記事の検索
3.フォロー機能
4.記事に対するコメント

１．フェイクニュース投稿

画像の右にあるフェイクするのボタンを押すと、記事作成フォームに飛びます。

そこでタイトル、フェイクニュースの内容、画像の選択をすればフェイクニュースは完成です。
次に確認画面にうつりそこで完了すれば最新のトレンドとして投稿が追加されます。

２．記事の検索

この検索窓に好きなワードを入力するとそれに関連したフェイクニュース
が読めます。

３．フォロー機能

ユーザー名のURLをクリックしてユーザープロフィールに移動すると以下の画面が
表示されます。「フォロー＋」と書かれたボタンを押すとそのユーザーをフォロー
することができます。

フォローしたユーザーは、自分の名前をクリックして出てくる欄の「フォロー」という項目
をクリックすればフォローしたユーザーとフォロワーの一覧が見られます。

上の写真の友達の投稿という項目をクリックするとフォローしたユーザーとフォロワーの投稿
が見られます。

４．記事に対するコメント

記事を読む画面の一番下側にコメント入力フォームがあります。
そこから自分のコメントを書き込めることができます。

以上がFakeNewsの機能及び使い方の説明でした。

命名規則について、PSRを参考にしてみた。

PSRってなに？

PHP Framework Interop Groupが策定しているPHPコーディング規約。

■wiki（PHP Standard Recommendation）
https://en.wikipedia.org/wiki/PHP_Standard_Recommendation

PHP Standard Recommendation（PSR）は、PHP Framework Interop Groupによって公開されたPHP仕様です。 JavaのJava Specification Requestと同様に、PHPのプログラミング概念の標準化に役立ちます。目的は、コンポーネントの相互運用性を有効にし、最適なプログラミングとテストの実践のための実証済みの概念を実装するための共通の技術的基盤を提供することです。 PHP-FIGは、いくつかのPHPフレームワークの創設者によって形成されています。[1] 各PSRはメンバーによって提案され、合意されたプロセスに従って一貫して行動するために、確立されたプロトコルに従って投票されます。

PHP Framework Interop Groupのサイト（https://www.php-fig.org/）

命名規則

参考にしたサイト

PHP-FIG
https://www.php-fig.org/psr/psr-1/

クラス名

スタッドリーキャップス（StudlyCaps）で宣言！
先頭文字と単語の区切りを大文字にする命名規則。

// StudlyCaps
class ClassName
{
}

定数

スネークケース&大文字で宣言！
単語の区切りをアンダースコア（_）、定数名は全て大文字

// StudlyCaps
class ClassName
{
    // snake_case
    const CONSTANT_NAME = 'name';
}

プロパティ

This guide intentionally avoids any recommendation regarding the use of $StudlyCaps, $camelCase, or $under_score property names.
Whatever naming convention is used SHOULD be applied consistently within a reasonable scope. That scope may be vendor-level, package-level, class-level, or method-level.

スタッドリーキャップス、キャメルケース、スネークケースどれ使ってもいいけど、
ベンダーレベル、パッケージレベル、クラスレベル、メソッドレベルで統一して下さいと

メソッド

ローワーキャメルケースで宣言！
先頭文字小文字の単語の区切りを大文字にする命名規則

// StudlyCaps
class ClassName
{
    // snake_case
    const CONSTANT_NAME = 'name';
    // camelCase
    public function methodName()
    {
    }
}

内容

パーフェクトPHP7章8章で扱うフレームワークがどのようなフレームワークなのかざっくりした説明と学習した際の感想などを書いてます。
技術的なことは特に記載されていません。
あらかじめご了承の上、記事をお読みになってください。

記事の構成

• MVCのそれぞれの役割
• 7章 フレームワークの構成
• 各クラスと他ファイルの役割
• 各クラスの関係と処理の流れ
• 8章 ミニブログアプリケーション
• 学習中の戸惑いなど
• 理解するために
• あとがき
• 脚注

MVCのそれぞれの役割¹

モデル

アプリケーションのビジネスロジックを担うのがモデルです。Webアプリケーションでは主に、データベースへアクセスしてデータの取得や変更を行う機能をモデルに記述します。

ビュー

出力を担うのがビューです。Webアプリケーションでは主にHTMLを出力しますので。ビューはHTMLの組み立てや情報の出力を行います。

コントローラ

ユーザのリクエストを制御し、モデルから情報を取得してビューに橋渡しするのがコントローラです。

7章 フレームワークの構成

パーフェクトPHPの7章のフレームワークは以下のように構成されます。

application/
  controllers/
  core/
    Application.php
    ClassLoader.php
    Controller.php
    DbManager.php
    DbRepository.php
    HttpNotFoundException.php
    Request.php
    Response.php
    Router.php
    Session.php
    UnauthorizedActionException.php
    View.php
  models/
  views/
  web/
    .htaccess
    index.php
  bootstrap.php

※フレームワークのコードについては技術評論社Webサイトを参照してください。

ライセンス
The MIT License
Copyright (c) 2010 Katsuhiro Ogawa
https://github.com/kenjis/perfect-php-mini-blog/blob/master/LICENSE

各クラスと他ファイルの役割²

Application.php

アプリケーション全体を表すクラスです。RequestクラスやSessionクラスの初期化、コントローラの実行などアプリケーションの全体の流れを管理します。

ClassLoader.php

オートロードに関する処理をまとめたクラスです。

Controller.php

モデルやビューの制御を行うコントローラです。今回はこのControllerクラスの中にアクションと呼ばれるメソッドを定義していきます。

DbManager.php

データベースへの接続情報や次に説明するDbRepositoryを管理するクラスです。

DbRepository.php

実際にデータベースへのアクセスを伴う処理を管理するクラスです。実施にはデータベース上のテーブルごとにDbRepositoryクラスの子クラスを作成します。今回のフレームワークではモデルに相当します。

HttpNotFoundException.php

ページが存在しないことを表す例外クラスです。

Request.php

ユーザのリクエストを表すクラスです。ユーザがリクエストした際のGETやPOSTパラメータ、URLなどの情報を管理します。

Response.php

リクエストに対するレスポンスです。最終的にユーザへ返すレスポンスの情報を管理します。

Router.php

ユーザがアクセスしてきたURLをRequestクラスから受け取り、どのコントローラを呼び出すかを決定します。これにより物理的なディレクトリ構造に縛られないURLの制御を可能にします。

Session.php

セッションを管理するクラスです。

UnauthorizedActionException.php

例外を用いたログイン画面への遷移のための例外クラスです。

bootstrap.php

オートロードを設定するためのファイル。

.htaccess

Apacheの設定を変更するためのファイル。

index.php

フロントコントローラにあたるファイル。

各クラスの関係と処理の流れ

それぞれのクラスの関係については以下の図 ³で表されます。
これらのクラスを使用したフレームワークをもとに8章ではミニブログアプリケーションを作成します。

以下は先ほどの画像にApplicationクラスでの処理の流れを記載したものです。
処理を追っていたときに迷子になることがあったので目印の変わりに処理の流れを記載してます。

(※表現を変えている箇所がいくつかあるので注意。例『$this->request』を『Request』と表記)

実際の処理の流れは以下の通りです。
まずはRequestクラスでリクエストを受け取りRouterでコントローラ名やアクション名などを取得します。
取得した値をもとにApplicationクラスのrunAction()メソッドでAccountControllerやStatusControllerといった使用するコントローラの決定とインスタンス化を行います(8章のミニブログアプリケーションで出てきます)。
次にControllerクラスのrun()メソッドで実行するメソッドの決定を行います。
実行したメソッド内でSessionクラスやDbManagerクラス(+DbRepositoryクラス)、Viewクラスとのやりとりが行われ見た目を構成していきます。
最後にResponseクラスのsend()メソッドにより出力されます。
以上が一連の処理の流れです。

8章 ミニブログアプリケーション

構成は以下の通り。

mini-blog.localhost/
  controllers/
    AccountController.php
    StatusController.php
  core/
    Application.php
    ClassLoader.php
    Controller.php
    DbManager.php
    DbRepository.php
    HttpNotFoundException.php
    Request.php
    Response.php
    Router.php
    Session.php
    UnauthorizedActionException.php
    View.php
  models/
    FollowingRepository.php
    StatusRepository.php
    UserRepository.php
  views/
    account/
      index.php
      inputs.php
      signin.php
      signup.php
    status/
      index.php
      show.php
      status.php
      user.php
    errors.php
    layout.php
  web/
    css/
      style.css
    .htaccess
    index_dev.php
    index.php
  bootstrap.php
  MiniBlogApplication.php

controllersディレクトリ、modelsディレクトリ、viewディレクトリ、webディレクトリやルート直下にクラスファイルが増えてます。
controllersディレクトリのクラスはControllerクラスを継承、modelsディレクトリはDbRepositoryクラスを継承、MiniBlogApplicationクラスはApplicationクラスを継承し、viewsのaccountディレクトリやそのファイルたちはControllerやメソッドに対応し、共通のレイアウトについてはlayout.phpとerrors.phpとして分けられています。
コードを見たい方は技術評論社Webサイトを参照してください。

学習中の戸惑いなど

• クラスやメソッドについて知識がほとんどないため、写経中は理解に努めてもぼんやりとしか意味がわからなかった。 （「引数とメソッド内の処理の関係などについてわかっていなかったこと」と「メソッドが他のメソッドとどう関連しているのかが全くわからず宙に浮いた処理の塊に見えたこと」が原因。今思うと不思議。）
• 今までは比較的単純なコードを写経して実行すればすぐに実行結果が見れていたのに対し、なかなか実行に移せない写経に少し飽きる。
• 様々な内部関数などが出てきて面食らう。(40近くありました。全ての関数に比べるとわずかですが初見ではこんなにいろんな関数などがあるんだと驚いてました。)
• ->や::に慣れない。
• ところで$thisとselfの違いって...
• 実際に動いたけど、どんな処理の流れなんだ。
• RouterクラスのcompileRoutes()メソッドとresolve()メソッドの正規表現に関する処理がよくわからない。(var_dump()で値が見られずに「なんで？」となってました。)
• Controllerクラスのrender()メソッドとViewクラスのrender()メソッドちょっとややこしいッ。

こんな感じで色々と戸惑ったりなかなか理解できなかったり「向いてないかもなぁ」と嘆きつつ学習してました。

理解するために

ひたすら処理の途中途中で値を出力しては処理を止めて記録する持久戦で理解に努め、以下のGIFにあるようにスプレッドシートに記録してました。(var_dump();exit()をかなり多用しました)

縦にカラフルな線があるのは処理の途中で他のメソッドの処理に移ったり戻ったりすることによってどこの処理をしているのかわからなくなるため階層と色を分けて表現することでどのクラスで処理しているのか少しわかりやすくなるかなと考えた結果です。
右側の薄い緑や紫の塗りつぶしは取得した配列の値などを記録している箇所です。
これらを出力される画面毎に記録していました。

　(↑文章の表現が怪しいですが当時そのままのものです。)

時間はかかりますし要領を得ていないと自覚していましたが、おかげでコードに対する苦手意識は軽減されましたし、当初に比べるとコードを読めるようになり処理の流れもわかるようになったので結果オーライだと思っています。

あとがき

ここまで読んでくださった方ありがとうございます。
冒頭にもあるように大したことは書いていないので技術目的の方ごめんなさい。
あとはパーフェクトPHPを選んだ理由などを少し書いています。
グダグタですのでご注意ください。

パーフェクトPHPを選んだ理由

パーフェクトPHPについては初版が2010年12月10日なので、記事を書いている現在ですでに約9年弱前のものになります。実際パーフェクトPHPの内容は古いという評価も見かけることはあります。
それでも私はパーフェクトPHPでフレームワークについて学ぼうと思いました。

理由は２つあります。

１つは古いという評価があるにも関わらず現在に到るまで出版され書店でも取り扱われ続けているということです。つまり現在でも十分に通用する基礎が記載されていると判断したためです。

２つめの理由は「Laravelなどのフレームワークが便利」ということを実感したかったからです。おそらく初めからLaravelなどのフレームワークを利用して勉強を始めると「みんな便利っていうけど一体何が便利なの？」とズレた基準が自身の中に生まれたり、自身の性格上、他にも残念な思い違いをしてしまうだろうと考えたためです。

まだLaravelをちゃんと学んでいないので実際に扱った際にどのように感じるかはわかりません。
できれば「え...めちゃくちゃ便利やん。初めから使えばよかった。」と感じることができたらと願っています。

7章8章を終えて

この章を通して学んだことを今後に活かすことができたらと願うと同時に活かすことができるよう努めようと思います。

これからプログラミングを学び始め方へ

これからプログラミングを学び始める方、学び始めたばかりの方はいきなりパーフェクトPHPを手に取らない方が良いと思います。
それよりも入門書であったり(シンプルなコードでお買い物機能実装できるものとか)、Progateのようなサービスを利用して慣れてきてから自分で何かしらのサービスを作るときや、もっと詳しいことを知りたいと思ったときに手に取ると良いかと思います。

以上です。

最後までお付き合いありがとうございました。

脚注

---

1. （出典： 小川雄大、柄沢聡太郎、橋口誠、「パーフェクトPHP」「第7章 フレームワークによる効率的な開発」『7.2.2 MVCモデル』2018年第8刷発行、200ページ） ↩

2. （出典： 小川雄大、柄沢聡太郎、橋口誠、「パーフェクトPHP」「第7章 フレームワークによる効率的な開発」『7.2.3 フレームワークの構造』200ページ、201ページ、『7.2.7 ClassLoaderクラス』204ページ、『7.2.8 bootstrap.php』206ページ、『7.2.9 フロントコントローラと.htacess』207、208ページ、『7.2.22 例外の活用』239ページ、『7.2.31 ログイン状態の制御』257ページ） ↩

3. （出典： 小川雄大、柄沢聡太郎、橋口誠、「パーフェクトPHP」「第7章 フレームワークによる効率的な開発」『7.2.4 フレームワークの処理の流れ』2018年第8刷発行、202ページ） ↩

これは2019年8月30日に開催したPHPerイベントYYPHP#98のイベントレポートです。

YYPHPは一言で「PHPerの部室」です。PHPについて、雑に、ゆるく、ワイワイ話し合う集いです。毎回お題を決めずに雑談を出発点にいろいろなことを突発的にやります。集まった人でコードリーディングをすることもあれば、一緒に開発ツールを触ってみたり、フレームワークについての情報交換をすることもあります。開催はほぼ毎週、高田馬場にて。

今回の配信動画

YYPHP#98「未経験から就職したとき、どういうことを意識したらいい？」 「LaravelのFacadeって使うべき？避けるべき？」 「プロダ... https://t.co/rpOf5xKr6x

— suin❄️TypeScriptが好き (@suin) August 30, 2019

過去回の配信動画

https://www.youtube.com/playlist?list=PLpOeTEye3Bg6PodrLHHC72jWMJYZz8VbG

前回 → YYPHP#97「掲示板を作るときに気をつけたほうがいいセキュリティ 」「PHPセキュリティのベストプラクティス」「掲示板のいいね機能の作り方」「MVCのServiceについて聞きたい 」「大規模インフラで向いているPHPの立ち位置とは」「Laravel向けに、AWSのセキュリティガチガチの構築スクリプトを作った話」 - Qiita

雑談

未経験から就職したとき、どういうことを意識したらいい？ (せの)

新人が入ってきたらどういうことを意識してもらいたいか？

メモをとること、など。

...

• 新人への指導経験のあるひといます？
  • はじめは丁寧にやりかたを教えてたが、途中からやめた。
    • 手順通りにやってもらうより、
    • 考え方を伝えたほうがいいのかなと思ったから。
    • 依頼されたことに対して、なんでやるのかその背景を聞くようにしてほしい。
  • 報告をとにかく早くして欲しい
    • 仕事が終わったタイミングと思われがち。
    • 仕事が止まっているときも報告してほしい。
    • つまっている時点で聞く。
    • 思っている10倍も20倍も早いタイミングで聞く。
    • 「〜で調べようと思ってますが、どうですか？」くらいでいい
    • これから作業しようとしている段取り、それを宣言するのも有用
      • それがだめだったら、「一緒に段取り考えてください」というのもいい
    • 段取りは、料理のレシピみたいに分解してくださいと伝えています。
      • それは新人に作ってもらってる？
        • 一度作ってもらうようにしてます
      • 大事な作業、本番公開などは、実行計画を作ってレビューしてもらうようにしている。
  • リモートの場合
    • まとめて投げてみるほうがいいと思う。
    • suinさんの分報が役立つのでは？
  • 新人教育する人へは仕事を減らして欲しい、新人教育に裂ける時間をあらかじめ作る事によりギスギスが減ると思う
• 新人として教えてもらう立場の人？
  • 業務的なことは
• 教える側
  • 忙しいオーラを出さないようにしてはいけない。
    • 新人が遠慮してしまうから。
    • もくもくと作業しているとき、表情が怖いと言われる……
      • Slackではニッコニコの絵文字ついまくるのはどう？
    • Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ〜Problemが10分で解決するチャットを作ろう | | Craftsman Software Inc.
      • リアルタイムに課題が解決しやすい
      • 質問のハードルがすごく低い
      • 分報、チームで使っているが、評判がいい
        • リーダーがどういうことをしているのかいちいち聞かなくていい
        • つまってそうなら、リーダーから能動的に聞きにいける
      • 分報を実施したんですけど、コミュニケーションを取る人/取らない人で格差が発生したので、チームメイトによると思います
      • 日報ですら読まない人いるので、意識改革的なハードル下げるアピールは必要かと思いますね。

1年半のサービス、ソースが汚い。リファクタリングどうしよう…… (ぴろし)

1年半くらい開発してきたサービス(オープンソース)がある。
ソースがどうしても汚くなってきている。
どうリファクタリングしていったらいいか？おすすめの方法を聞きたい。

既存のサービスをリファクタリングしている方がいたら聞きたい。

...

• どうにもならなかったら非互換のバージョンを作る
• テストってあるんですか？
  • リファクタリングするならテストがあるのが前提
    • 最初にテストを書いて、リファクタリングする
      • ここをきれいにしたい、という部分にテストを書く
      • 今の挙動を確実にする
      • リファクタリングする
      • テストで壊れてないことを確認する
    • 全部テストを書くイメージでした
      • そんなことない、必要なところ、変えたいところだけテストを書けばOK
• テストファースト
• テストのことを全く考えないコードを書いてると、テストを書くためにリファクタリングってことありませんか？
  • 普通にある
• 急ぐべきところと急がないところは見極めるべき
  • コアに近い部分
  • いろんなところで使われる
  • 重要なコンポーネント
  • メリハリをつけるといい
• 現在テストがなければ Laravelの次期LTSをベースに作り直してもいいんじゃないかと思う
  • 非互換にするなら
• ボーイスカウトルール
  • 来たときより綺麗にして帰る

シナリオクラスってビジネスロジック？ (よだか)

『現場で役立つシステム設計』を読んでいる。複合サービスクラス(別名 シナリオクラス)というのがあって、それを作るとメソッドが実行される順番を制御できる。しかし、メソッドの順番ってビジネスロジックじゃないの？という疑問。

...

• ｻｯﾊﾟﾘﾜｶﾗﾝ
• ビジネスロジックかどうかと言われると、そうだと思う。
• 注文を受け付けて、在庫を確認する、出荷する
  • その流れを制御するためにシナリオクラスにまとめるのはどう？
    • いいと思う
• Clean Architecture
  • ユースケースと呼ばれる
• MVC
  • コントローラに書かれがち
• IDDD
  • アプリケーションサービス
• レイヤーが1つ増えるごとに1.5倍ずつ難しくなるイメージ

LaravelのFacadeって使うべき？避けるべき？ (きたむら)

普段はUseして書く事が当たり前だったので、Facadeは使った方がいいのか。それとも使わなくていいなら使わないべきなのか。完全に理解出来ていないので、使い分けをどうしているのかが知りたい。

...

• Facadeで用意されているサービスがあるならそのまま使っちゃえばいいのでは?
• ここはFacadeでここはFacadeじゃないってなるとわかりづらくなる面がある
• Laravel ファサードを利用しないメリット - ytake blog
  • Facadeをつかないほうがちょっとはやい
  • newしなくていい
    • DIされるから
• 使っても使わなくても、、、楽になるなら使ってもいいのでは
• サービスプロバイダを先に覚えたので、Facadeを使ってこなかった
• コントローラをテスタブルにしたいなら、Facadeよりサービスプロバイダがいいかも
  • Laravelのファサードは中でDIコンテナ使っているから結合が固定されるみたいなことはないので、テストで入れ替えるとかそういうのはできるように考慮されているんですよね。
• Taylor Otwellの答え
  • Response: Don’t Use Facades | PHPNews
    • 2014年1月の記事(Laravel v4.1のころ)
    • 古すぎて当てにならない気も
• コンストラクタインジェクションをするならFacadeは不要だから、Facadeで全部書くみたいなのは無いかな
• コントローラじゃないところで使うのはやめた方が良いかも
• Authとかはもう完全的にFacade使っちゃう
• どこでも使うものはFacedeにするのはありだと思う
• ミドルウェアとかはFacedeでいいとして、ビジネスロジックはコンストラクタインジェクションにしったほうがいいと思う
• 複数人の開発だとどっちか決めないと人によってまちまちになる

Laravelに依存したDDDってあり？ (よだか)

Laravelでドメインモデルを作っていこうと思っている。
とりあえず、フレームワークの機能に依存させて作っていいかと思っている。
(本当はだめだと思うが)。
RequestとResponseだけに依存して、作るのはありか？
それをやるなら、DDDやらないほうがいいのか？

...

• DDDは堅牢なシステムを作る手法で、インフラに依存しない設計手法
  • 依存しないかどうかは、DDDの本質ではない
• なぜフレームワークに依存しちゃいけない？
  • アプリケーションと業務のライフサイクルが別
  • アプリケーションと心中しないために
• フレームワークを一生変えない可能性がある
• 切り離そうとすると、切り離せるけど、開発コストはだいぶ高まる
• EC-Cubeでも似たような乗り換え問題が発生している
  • 2系: 5.6までしか対応していないので乗り換えたい
  • 3,4系へは互換性がなく乗り換えられない

プロダクション環境ってみんなどうやって構築してる？ (れおりん)

サービスとかやってる人がいたら、こんなふうにやっているというのを教えてほしいです。

...

• サービスやってる方、教えて。
  • AWSのEC2に入ってシェルを実行
  • マンパワーでやっちゃってる
  • WinMergeで差分確認して、差分をSCPでアップロード
• セキュリティの対策ってどういうのあがあります？
  • WAF置いたり
  • subnet分けたり
  • 踏み台サーバ置いたり
• Deployerを使ってデプロイしてみたら想像以上に楽だった - Qiita
• DeployerでLaravelをデプロイする - Qiita
  • Deployerは使ったことないけど興味はある
• GitHub ActionsでLaravelデプロイしてます

SPAのセキュリティって何を注意したらいい？ (にしかわ)

JavaScriptはソースが見れるからセキュリティが弱いって上司に止められた。

Laravelを使っている。
非同期処理が多いところは、Vue。ログインまわりは、Bladeで書いてる。

...

• ソースが見れるかどうかはセキュリティにあんまり関係ない。
  • 攻撃者はソースコード見れる見れないに関係なく、「弱点」をついてくる。
• ちゃんと書かれてるかどうか。
• Vue.js
  • 認証周りのAPI使うときはIP制限かけたりしてる
• 認証情報をlocalStorageに入れるのは危ない
  • Cookieを使う
• XSS
  • サーバサイドでエスケープしててもクライアントサイドでもエスケープする必要がある
• 大量の「はまちちゃん」を生み出したCSRFの脆弱性とは？ - ITmedia エンタープライズ
• SPAにする必要があるか
  • 考える必要のある事柄、場所が増えるから
• ソースコードは難読化できる
  • 見えなくすることはできない
• サーバサイドは送られてきたデータを全く信用せずにバリデーションするというのは変わらない。

TypeScriptとNuxt、次に勉強するならどっち？ (にしかわ)

ある程度Vueを分かってきたので。

...

• どっちも並行してやったらいい。
• TypeScriptってゆるやかにいける
  • .tsで作ってJSを書いて、徐々に型をつけていく、というのもあり
• Nuxtって何？
  • Laravelのフロントエンド版(語弊)
  • Vueとの違い
    • Vue.jsが使われているフロントエンドのフレームワーク
  • Nextは、Reactが使われているフロントエンドフレームワーク
  • Nextがあって、NuxtがVue版として出た
  • 「NuxtにとってのVue」は、「LaravelにとってのBlade =」という似た立ち位置
  • PWA、SSRをできる。
  • サーバサイドはNode?
    • SSRするならNode
    • 画面だけなら、Firebase使ってサーバを持たないというのも結構ある

YYPHPは毎週やってます

PHPについてワイワイ話したい方は、YYPHPのイベント情報をチェックしてみて下さい。

以上、YYPHPのレポートでした。次回もワイワイやっていきたいと思います！ では、また来週！

//保存するファイルのファイルポインタを開く
$fp = fopen('/var/www/html/laravel/public/'.$file_name, "w");

//fputcsvでCSVデータを作る
foreach ($sheet->toArray() as $val) {mb_convert_variables('SJIS-win', 'UTF-8', $val);fputcsv($fp, $val);}

//ファイルポインタを閉じる
fclose($fp);

記事のゴール

Firebase Authenticationを使って認証するBear.Sunday用のモジュールを実装したときに得た知見をまとめる

JWT認証がよくわからない

ちゃんとRFC7519があった

JWTの基礎的なところはライブラリがすでに存在していると思うのでそちらを利用するとして、
どのClaimに何を入れるべきなのか、結構ライブラリによってもズレていたので覚え書き。

ユーザ識別子はどこに格納するべきか

subが一般的？

4.1.2. "sub" (Subject) Claim

The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.
-----
「サブ」（サブジェクト）クレームは、JWTの主題。JWTのクレームは通常、ステートメントです。主題について。サブジェクト値は、発行者のコンテキストでローカルに一意であるか、グローバルに一意である。

たまにaudを使っているライブラリもあったが、audはJWTを処理するアプリケーションの識別子だと思われる。

参考：
https://tools.ietf.org/html/rfc7519
https://www.iana.org/assignments/jwt/jwt.xhtml

デバッグ

JWTのデバッグをするならhttps://jwt.io/が便利

IDaas？

最近流行り(?)のIDaaSについてまとめます

Identity as a Serviceの略称で、アイデンティティ（Identity）の管理をSaaSやIaaSなどと同じくクラウドにて管理するサービスのこと

簡単に言うと、
「アプリケーションで必要とする認証まわりの機能（ユーザー管理・権限管理など）を提供してくれる」
クラウドサービス。

JWTはどう送る？

決まっていない？RFC7519には以下のように記載があるが、それに限らない。

JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters.
-----
JSON Web Token（JWT）は、HTTP AuthorizationヘッダーやURIクエリパラメーターなど、スペースに制約のある環境向けのコンパクトなクレーム表現形式です。

ライブラリによってはAuthorizationヘッダに入れてるものもあれば、Cookieに入れているもの、クエリストリングに入れるもの、それらすべて許容するものなど様々。
体感だがRFC6750に沿う形でAuthorization: Bearerを使っているライブラリが多かったように思う。

参考：
https://tools.ietf.org/html/rfc6749
https://tools.ietf.org/html/rfc6750
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた

エラーレスポンスはどういう形と内容にするべき？

RFC6750に準拠するのであれば、レスポンスに「WWW-Authenticate」ヘッダーを含めなければならない。

参考：
https://tools.ietf.org/html/rfc6750
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた

テスト

ベストプラクティス
実装ではなく、インターフェイスをテストする
フェイククラスを好む。スタブはOK。モックには批判的な意見もあり複雑なものを避ける。

https://bearsunday.github.io/manuals/1.0/ja/test.html

tl;dw: Stop mocking, start testing

・Share mocks among test modules.
・Maybe you don’t need a mock: if an object is cheap, then don’t mock it.
・If you need a mock, have exactly one well-tested mock.
-----
・テスト間でモックを共有しましょう。（N個のモックオブジェクトの修正を必要としないように）
・オブジェクトがチープならモック化するのをやめましょう。必要ありません。
・モックが必要な場合は、十分にテストされたモックを1つだけ用意してください。

https://nedbatchelder.com/blog/201206/tldw_stop_mocking_start_testing.html

テストダブル

テストダブル (Test Double) とは、ソフトウェアテストでテスト対象が依存しているコンポーネントを置き換える代用品のことです。テストダブルは以下のパターンがあります。

スタブ (テスト対象にダミーデータを与える)
モック (下位モジュールを正しく利用しているかを実際のモジュールを用いないで検証)
フェイク (実際のオブジェクトに近い働きをするがより単純な実装を使う)
スパイ (実際のオブジェクトに対する入出力の記録を検証)

https://bearsunday.github.io/manuals/1.0/ja/test.html#%E3%83%86%E3%82%B9%E3%83%88%E3%83%80%E3%83%96%E3%83%AB

まだよくわからない…上記の4つに加えてダミーオブジェクトもあるらしい。

ダミーオブジェクト（厳密にはテストダブルではないらしい）

Dummy objects are objects that the System Under Test (SUT) depends on, but they are actually never used. A dummy object can be an argument passed to another object, or it can be returned by a second object and then passed to a third object. The point is, our tested class never actually use these dummy objects. At the same time, the object must resemble a real object; otherwise, the receiver may refuse it.
-----
ダミーオブジェクトは、テスト対象システム（SUT）が依存するオブジェクトですが、実際には使用されません。ダミーオブジェクトは、別のオブジェクトに渡される引数にすることも、2番目のオブジェクトから返されて3番目のオブジェクトに渡すこともできます。重要なのは、テストされたクラスが実際にこれらのダミーオブジェクトを使用しないことです。同時に、オブジェクトは実際のオブジェクトに似ている必要があります。そうしないと、受信者が拒否する場合があります。

https://code.tutsplus.com/tutorials/all-about-mocking-with-phpunit--net-27252

class CarController
{
    public function getReadyToGo(Electronics $electronics, Lights $lights)
    {
        $electronics->turnOn($lights);

        return true;
    }
}

class CarControllerTest extends TestCase
{
    public function testItCanGetReadyTheCar()
    {
        $SUT = new CarController();
        $electronics = new Electronics();
        $dummyLights = $this->createMock(Lights::class);

        $this->assertTrue($SUT->getReadyToGo($electronics, $dummyLights));
    }
}

スタブ

実際のオブジェクトを置き換えて、設定した何らかの値を (オプションで) 返すようなテストダブルのことをスタブといいます。スタブを使うと、SUT が依存している実際のコンポーネントを置き換え、SUTの入力を間接的にコントロールできるようにすることができます。 これにより、SUTが他の何者も実行しないことを強制させることができます。

https://github.com/sebastianbergmann/phpunit-documentation/blob/master/src/3.6/ja/test-doubles.xml

class CarController
{
    public function goForward(Electronics $electronics, StatusPanel $statusPanel = null)
    {
        $statusPanel = $statusPanel ?? new StatusPanel();
        if ($statusPanel->engineIsRunning() && $statusPanel->thereIsEnoughFuel()) {
            $electronics->accelerate();
        }
    }
}

class CarControllerTest extends TestCase
{
    public function testItCanAccelerate()
    {
        $SUT = new CarController();
        $electronics = new Electronics();

        $stubStatusPanel = $this->createMock(StatusPanel::class);
        $stubStatusPanel->method('engineIsRunning')->willReturn(true);
        $stubStatusPanel->method('thereIsEnoughFuel')->willReturn(true);

        $SUT->goForward($electronics, $stubStatusPanel);
    }
}

ここではスタブのメソッドが何回呼ばれる、などはテストしない。それはモックの役割になる。

モック

実際のオブジェクトを置き換えて、(メソッドがコールされたことなどの) 期待する内容を検証するテストダブルのことをモックといいます。モックオブジェクトはSUTの間接的な出力の内容を検証するために使用する観測地点です。一般的に、モックオブジェクトにはテスト用スタブの機能も含まれます。まだテストに失敗していない場合に、間接的な出力の検証用の値をSUTに返す機能です。したがって、モックオブジェクトとはテスト用スタブにアサーション機能を足しただけのものとは異なります。それ以外の用途にも使うことができます。

https://github.com/sebastianbergmann/phpunit-documentation/blob/master/src/3.6/ja/test-doubles.xml

class CarController
{
    public function goForward(Electronics $electronics, StatusPanel $statusPanel = null)
    {
        $statusPanel = $statusPanel ?? new StatusPanel();
        if ($statusPanel->engineIsRunning() && $statusPanel->thereIsEnoughFuel()) {
            $electronics->accelerate();
        }
    }
}

class CarControllerTest extends TestCase
{
    public function testItCanAccelerate()
    {
        $SUT = new CarController();

        $mockElectronics = $this->createMock(Electronics::class);
        $mockElectronics->expects($this->once())->method('accelerate');

        $stubStatusPanel = $this->createMock(StatusPanel::class);
        $stubStatusPanel->method('engineIsRunning')->willReturn(true);
        $stubStatusPanel->method('thereIsEnoughFuel')->willReturn(true);

        $SUT->goForward($electronics, $stubStatusPanel);
    }
}

スタブにアサーションをつけたらモック、と思いがちだけど目的が全く違うってことかな？
スタブはSUTへの入力を固定する、モックはSUTから依存するオブジェクトへの出力を検証する。

スパイ

使うべきタイミングがよくわからなかったので割愛

フェイク

フェイクオブジェクトは実際に動作するよう実装されてはいるが、手抜きがされているので製品版には向かない（InMemoryDatabaseが良い例である）。

https://bliki-ja.github.io/TestDouble/

いろんな意味に捉えている人がおり、スタブとほぼ同じ意味で使われていることも多い。
BEAR.SundayのFakeディレクトリ以下の実装を見ると、上記のフェイクの意味＋スタブの意味＋テストダブル以外の意味、があるように思える。

PHP-CS-Fixer

出たエラーの意味がわからないとき

$ php-cs-fixer describe <name>

http://fivestar.hatenablog.com/entry/2017/03/30/233744

または

PHP-CS-Fixer configuration

マスターデーターをDBで管理する際にSQLのJoinで一緒に取得する場合も多くありますが、実装上で可読性や色んな理由で別のSQLで参照場合もあると思います。

やりたいこと

実装したらあまり気にしなくてもシステム上でCache化と更新が行うようにしたい。

実装

モデルのsavedイベント利用してCacheを削除することでデーターが更新された場合は
Cacheが取得されるタイミングで更新されることを実装してみました。

/app/Models/MasterModel.php

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\Facades\Cache;

class MasterModel extends Model
{
    /**
     * Table
     *
     * @var string
     */
    protected $table = 'mst_sample';

    /**
     * The attributes that should be mutated to dates.
     *
     * @var array
     */
    protected $dates = ['created_at'];

    /** updated_atは使用しない */
    public $timestamps = false;

    /**
     * The "booting" method of the model.
     *
     * @return void
     */
    public static function boot()
    {
        parent::boot();

        self::saved(function($master) {
            Cache::forget('master.id.'.$master->id);
        });
    }

    /**
     * IDでマスター情報を取得
     *
     * @param string $id
     * @return mixed
     */
    public static function findWithCache($id = null) {
        $ret = Cache::rememberForever("master.id.{$id}", function() use($id) {
            if (is_null($id)) {
                return null;
            }
            return static::find($id);
        });

        return $ret;
    }
}

もちろん、親のfind等をOverrideして使っても良いかと思います。

Deployerを利用してLaravelをデプロイするとデプロイユーザーの設定によってログファイルのPermissionエラーが発生します。

サーバーでの対応

ユーザーのGroup設定やファイルが作成する時のディフォルトPermissionの設定を変える等で対応はできると思いますが、ユーザーの設定ができないサーバーを利用していると難しいと思います。また、設定が面倒と考える方もいると思います。

ConsoleとHttpのログファイルを分ける

logging.phpのtapの設定を行います。

config/logging.php

        'daily' => [
            'driver' => 'daily',
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
            'days' => 7,
            'tap' => [App\Logging\SapiLogTap::class],
        ],

ファイル名を分けるクラースを作成します。

app/Loggin/SapiLogTab.php

<?php

namespace App\Logging;

use Monolog\Handler\RotatingFileHandler;

/**
 * ログファイルを出力する
 */
class SapiLogTap
{
    /**
     * ログファイル名にインターフェイスの型を入れる
     *
     * @param  \Illuminate\Log\Logger $logger
     * @return void
     */
    public function __invoke($logger)
    {
        foreach ($logger->getHandlers() as $handler) {
            if ($handler instanceof RotatingFileHandler) {
                // ログハンドラーがRatationFileHandlerの場合
                // PHPの間のインターフェイスの型を取得
                $sapi = php_sapi_name();
                // ファイルのフォーマットを定義
                $handler->setFilenameFormat("{filename}-$sapi-{date}", 'Y-m-d');
            }
        }
    }
}

ファイルのPermissionの変更

設定ファイルの修正でできるようです（検証しておりません）。参考

普段何気なく使っている変数への代入ですが、値渡し以外にも参照渡しという方法があるので、
参照渡しと値渡しの概念についてまとめていきます。

変数

• 値渡し
  • 変数の中の値を渡す

$x = 1; //変数$xに1を代入
$y = $x; //変数$yに$xの値を代入　値渡し
$x = 6; //変数$xに6を代入
print $y;

//結果
1 //$yは$xの値の更新の影響を受けない

• 参照渡し
  • 変数のメモリアドレス値を渡す
  • 参照渡しする際は、$の前に「&」を付ける

$x = 1; //変数$xに1を代入
$y = &$x; //変数$yに$xのメモリアドレスを代入　参照渡し
$x = 6; //変数$xに6を代入
print $y;

//結果
6 //$yは$xと同じメモリアドレスを見ているので、$xの値の6が、$yとして出力される

配列

＊後で書く

Composerを使ってLaravelをインストールしたときに並行してやったことがいくつかあるので、それの個人的な覚書です。環境は以下の通り。

• Mac OS Mojave (バージョン 10.14.3)
• MacBook Pro (Retina, 13-inch, Early 2015)

Composerのインストール

https://getcomposer.org/

Composerは、PHPのパッケージ管理システムあらため、依存関係解決ツールのこと。プロジェクトで使用するライブラリやパッケージを管理してくれ、こちらがあまり意識しなくても必要な時に、必要なバージョンのライブラリなりを一緒にダウンロードしてきてくれる。あるライブラリを使うには他のあるライブラリが必要で・・・みたいなときに丸っと面倒を見てくれるわけだが、その依存関係について詳しくは他の方の記事を参考に。

参考：
composerとは？
PHP開発でComposerを使わないなんてありえない！基礎編
composerとは
PHPのライブラリ管理ツール「Composer」入門

プロジェクトごとにComposerをインストールする（ローカル）かPC全体で共有する（グローバル）かは、どのディレクトリにインストールするかで変わってくる。いったん自分はユーザーホームのディレクトリに入れることにする。
Composerインストールのコマンドはこちら。

sudo curl -sS https://getcomposer.org/installer | php

バージョンが変わればURL等も変化するかもしれないので、公式サイトも要確認。
Mac, Linux系のインスタレーションはこちら。
https://getcomposer.org/doc/00-intro.md#installation-linux-unix-macos

Composerインストール後は、インスタレーションにもあるように composer.phar のファイルを移動する。そうすることで、どこからでもcomposerのコマンドを実行できる。

mv composer.phar /usr/local/bin/composer

Composerの光遅い問題について

Composerを使っていると、遅い！と感じる人が一定以上いるらしい。
アジア圏に顕著で、Composerを走らせたときに参照されるサーバは北米やフランスにあるので物理的な距離の問題があるし、光ファイバーとか使っても必要な数々のリクエストをこなすためには地球何周分もの距離をデータが行き来することになって光というものの速度自体が速くならない限り速くするのは無理、という結論にぶち当たるらしい。そこで、Composerを速くするための対応策として国内ミラーと高速化プラグインを作った方がいらっしゃる。
3年くらい前の出来事だけど今でも有用と思われるし、そのプラグインはまだComposer本体にはマージされていないので、詳しくはご本人のスライドや他の方のまとめを読むと良いと思う。スライドは最後まで見るとちょっと感動する。

なお国内のミラーに参照先を変える＆高速化プラグインインストールには、Composer本体をインストール済みの人であれば、以下のコマンドを走らせるだけでOK。

composer config -g repos.packagist composer https://packagist.jp && composer global require hirak/prestissimo

参考：
Composerを速くするために必要だったもの/composer-keynote
composerの遅さをまじめに考える #phpstudy
光遅い問題を克服してcomposerを10倍速くした話
光遅い問題に対応して Composer を100倍速くする
Composerの実行速度を高速化する方法
GitHub: Composer/Parallel downloader #5293
curl を使って composer update を 2 倍速くする
composer searchが非常に遅い件
composer searchが速くなってた
PHPの生みの親，ラスマス・ラードフ氏インタビュー

Laravel Debugbarのインストール

Laravelでの開発に便利そうなので導入。

インストールコマンドは下記だが、--devのオプションがないと本番環境で実行されてパスワードが丸見えになるとかなんとか。

composer require barryvdh/laravel-debugbar --dev

Debugbarを無効にしたいときは.envに以下を挿入。true/falseで切り替え可能。

DEBUGBAR_ENABLED=false

本番環境でも使いたいとか、詳細や各種設定値は、参考記事がとてもきれいにまとまっていたので割愛。

参考：
Laravel5.7: Laravel Debugbarを使う
laravel5.6, 5.7 laravel-debugarを導入する！
laravelデバッグバーの導入

今日はそんな感じです。

Laravelをインストールしたときに並行してやったことがいくつかあるので、それの個人的な覚書です。環境は以下の通り。

• Mac OS Mojave (バージョン 10.14.3)
• MacBook Pro (Retina, 13-inch, Early 2015)

Laravelインストール前

Composerのインストール

https://getcomposer.org/

Laravelをインストールするのに必要なステップ。Composerは、PHPのパッケージ管理システムあらため、依存関係解決ツールのこと。プロジェクトで使用するライブラリやパッケージを管理してくれ、こちらがあまり意識しなくても必要な時に、必要なバージョンのライブラリなりを一緒にダウンロードしてきてくれる。あるライブラリを使うには他のあるライブラリが必要で・・・みたいなときに丸っと面倒を見てくれるわけだが、その依存関係について詳しくは他の方の記事を参考に。

参考：
composerとは？
PHP開発でComposerを使わないなんてありえない！基礎編
composerとは
PHPのライブラリ管理ツール「Composer」入門

プロジェクトごとにComposerをインストールする（ローカル）かPC全体で共有する（グローバル）かは、どのディレクトリにインストールするかで変わってくる。いったん自分はユーザーホームのディレクトリに入れることにする。
Composerインストールのコマンドはこちら。

sudo curl -sS https://getcomposer.org/installer | php

バージョンが変わればURL等も変化するかもしれないので、公式サイトも要確認。
Mac, Linux系のインスタレーションはこちら。
https://getcomposer.org/doc/00-intro.md#installation-linux-unix-macos

Composerインストール後は、インスタレーションにもあるように composer.phar のファイルを移動する。そうすることで、どこからでもcomposerのコマンドを実行できる。

mv composer.phar /usr/local/bin/composer

Composerの光遅い問題への対応

Composerを使っていると、遅い！と感じる人が一定以上いるらしい。
アジア圏に顕著で、Composerを走らせたときに参照されるサーバは北米やフランスにあるので物理的な距離の問題があるし、光ファイバーとか使っても必要な数々のリクエストをこなすためには地球何周分もの距離をデータが行き来することになって光というものの速度自体が速くならない限り速くするのは無理、という結論にぶち当たるらしい。そこで、Composerを速くするための対応策として国内ミラーと高速化プラグインを作った方がいらっしゃる。
3年くらい前の出来事だけど今でも有用と思われるし、そのプラグインはまだComposer本体にはマージされていないので、詳しくはご本人のスライドや他の方のまとめを読むと良いと思う。スライドは最後まで見るとちょっと感動する。

なお国内のミラーに参照先を変える＆高速化プラグインインストールには、Composer本体をインストール済みの人であれば、以下のコマンドを走らせるだけでOK。
Laravelのインストールに絶対に必要というわけではないが、なんならLaravelインストール後でも大丈夫なのでやっておいて損はないと思う。

composer config -g repos.packagist composer https://packagist.jp && composer global require hirak/prestissimo

参考：
Composerを速くするために必要だったもの/composer-keynote
composerの遅さをまじめに考える #phpstudy
光遅い問題を克服してcomposerを10倍速くした話
光遅い問題に対応して Composer を100倍速くする
Composerの実行速度を高速化する方法
GitHub: Composer/Parallel downloader #5293
curl を使って composer update を 2 倍速くする
composer searchが非常に遅い件
composer searchが速くなってた
PHPの生みの親，ラスマス・ラードフ氏インタビュー

Laravelインストール後

Laravel Debugbarのインストール

Laravelでの開発に便利そうなので導入。

インストールコマンドは下記だが、--devのオプションがないと本番環境で実行されてパスワードが丸見えになるとかなんとか。

composer require barryvdh/laravel-debugbar --dev

Debugbarを無効にしたいときは.envに以下を挿入。true/falseで切り替え可能。

.env

DEBUGBAR_ENABLED=false

本番環境でも使いたいとか、詳細や各種設定値は、参考記事がとてもきれいにまとまっていたので割愛。

参考：
Laravel5.7: Laravel Debugbarを使う
laravel5.6, 5.7 laravel-debugarを導入する！
laravelデバッグバーの導入

今日はそんな感じです。

概要

環境ごとに値が変わるものは.envファイルに定義するのが多いと思います。
その際、.envファイルに定義した値を取得する際にはconfig以下のファイル経由での取得（config関数）することと書かれてますが、
たまにenv関数を使用してそのまま定義した値を取得する処理が書かれていることも多く見られるので、
それぞれの関数を使用して、config:cacheした後と前での.envの定義した値の取得検証をしてみます。

Configuration - Laravel - The PHP Framework For Web Artisans

設定値と確認方法

検証に使用したLaravelのバージョンは5.8.26です。
（環境はHomestead（8.6.0）を使用しました。）

また、基本的に.env以外はデフォルト値です。

.env

APP_NAME=Laravel
APP_ENV=local
APP_KEY=**********************

config\app.php

<?php

return [

    // ～省略～

    /*
    |--------------------------------------------------------------------------
    | Application Environment
    |--------------------------------------------------------------------------
    |
    | This value determines the "environment" your application is currently
    | running in. This may determine how you prefer to configure various
    | services the application utilizes. Set this in your ".env" file.
    |
    */

    'env' => env('APP_ENV', 'production'),

値の確認は以下のようにvar_dumpを使用

resources\views\layouts\app.blade.php

    var_dump(config('app.env'));
    var_dump(env('APP_ENV'));
    exit;

config:cache前

まずconfig:cacheする前の値を取得してみます

config:cacheする前はconfig関数で取得するとnullが帰ってくるようです。※

※nullが返るのは検証した際の環境がおかしかったかもしれません。（コメント欄見てください）

config:cache後

以下のコマンドを実行して再度、値の確認をしてみます

php artisan config:cache

env関数の方はnullが返るようになりました。
そしてconfig:cache後はconfig関数の方は定義した値を取得できるようになりました。

config:cache後にconfig:clear

config:cache後に以下のコマンドを実行後、値の確認をしてみます

php artisan config:clear

両方の関数で.envの定義した値を取得できました。

おまけ（.envファイルからAPP_ENV=local行を削除）

.envファイルからAPP_ENV=localを丸ごと削除した際に各関数を実行してみる。

.env

APP_NAME=Laravel

APP_KEY=**********************

以下tinker(laravel用REPL)で実行した際の様子

>>> var_dump(config('app.env'));
string(10) "production"
=> null
>>> var_dump(env('APP_ENV'));
NULL
=> null
>>>

結果、config関数はconfig\app.phpで設定されている値を取得しますが、env関数はそのままnull返すようです。
この結果なのでどちらにしてもconfig関数使った方がよさそうですね。

おわり

• config関数で定義値取得するように書いてた場合、config:cacheし忘れてたら大変なことになりそう

参考URL

• Configuration - Laravel - The PHP Framework For Web Artisans
• 設定 5.8 Laravel

CIでPHP CodeSnifferでチェックするとき、
エラーは検出したいけど、警告は対象としたくないという場合があるかと思います。
ググったところすぐにやり方が見つからなかったのでここに記しておきます。

いろいろやり方はあるかと思いますが、コマンドのオプションを指定することで解決するやり方を紹介します。
コマンドのオプションに--warning-severityを指定すれば警告を黙らせることができます。

たとえばLine exceeds 120 characters;の警告を対象から外したい場合、

vendor/bin/phpcs --warning-severity=6 --standard=PSR2 ./src

というようにwarning-severityのレベルを6以上を設定すると黙らせることができます。
もちろん警告だけでなくエラーのレベルも--error-severityで指定することができます。

詳しくは 公式のドキュメント をご参照ください。