PHPカンファレンス関西2017

PHPカンファレンス関西2017に参加してきました！
それぞれの登壇でまとめられたものをご紹介いたします。

PHPの現場から

  • PHPはドキュメントが整っていることが素晴らしい
  • PHP The Right Way
    • PHPの現場でのノウハウや最近の考え方が書かれてる
  • PHPには型がない？
    • 変数に型がないだけで値には型がある
    • 型宣言
  • 型を明示するメリット
    • 意図しない値（型）を防ぐ
    • コードの意図を明確にでき、IDEにも伝えられる
    • 暗黙的型変換を防ぐ
  • 型の検査
    • IDE
    • Phanなどの静的解析ツール
    • 自動テスト

オブジェクト指向開発言語

  • オブジェクト指向開発に必要なものが整っている
    • クラス、継承、カプセル化
    • 型宣言
    • インターフェイス、抽象クラス
    • 例外、トレイト
  • DDDの流行でOOPの再評価がされている
    • DDD in PHP
  • オブジェクトを扱い方がシンプルになるよう言語機能として用意されている
    • ArrayAccess　[]で値にアクセスできる
    • Traversable　オブジェクトをforeachで回せる

ステートレスなランタイム

  • PHPの実行順序　リクエストが来る毎にこれが行われている
    1.HTTPリクエストが来る
    2.PHPコードをコンパイル（opcode生成）
    ・OPCacheで高速化できるのは2の動作を省けるため
    3.実行環境を初期化
    4.opcodeを実行
    5.HTTPレスポンスを返す
  • 単一リクエストで閉じている
  • リクエスト毎にリセットするので何も共有しない、何も残さない
  • メリット
    • アプリケーション開発だけに集中できる
      • リクエストで必要なメモリしか使わないためメモリリーク、GCが起こりにくい
      • うっかりデータを共有しての事故がない
    • 今の潮流(クラウド、サーバーレス)との親和性がある

PHPの思想

  • PHPは歯ブラシのようなものです
  • PHP=ツール
    • 誰もが使えるツール
    • 使う人を否定しない言語
  • PHP=つなぐ言語
    • glue言語

PHPエンジニアよ胸を張れ！

  • 世界中で多くのシステムを支えている言語
  • PHPから言語を変えたところでどうなるか？
  • 他の言語ユーザに何言われても気にするな

最近のPHPがわからない人のための基本文法おさらい講座

  • php7リリースから約1年半
  • php5.6が2018/12/31にサポート終了
    • 今からPHP5系で実装するやつおる？

ライブラリ管理

  • Composer使うメリットを知ろう
    • require_once祭り殺し
      • ライブラリをいちいちrequireするのは面倒
      • 配置がプロジェクトごとに異なる
      • smarty使ってるやつおる？
    • ライブラリバージョンが分かりやすい
  • 最近の記法を覚えよう
    • ShortArraySyntax
    • null合体演算子
    • 三項演算子の省略記法
  • private functionじゃなくてclousureを使おう
    • JSなどでおなじみのクロージャ
    • use句でレキシカルスコープの利用も可能
    • 処理を変数に閉じ込めて引数渡しで持ち回す
  • share srevices
    • php5.4以降のtrait
    • 多重継承も可能
  • type hinting
    • 処理の引数が配列の場合は何をどういう形で受け取るのか不明になる
    • 複雑な引数、クラス型を指定することができる
    • php7から戻り値の値を指定することも可能になった
    • 何を受け取って何を返すのかを明記できる
  • 名前空間
  • ビルトインサーバ
  • assert関数　　などなど…

技術は変わった、現場は…？

  • 新しい技術は必ず必要というわけではない
  • 何故その技術が必要だったのか、どのように導入されたかをチェックしよう
  • 現場を変えるには変化に対するコストを小さくするサイクルを作る

パネルディスカッション 〜PSRとDIとフレームワーク〜

  • DI設計
    • 純粋な単体テスト・テストファーストが簡単に
    • PHPUnitでテストするためにフレームワーク起動が不要
    • EC-CUBE作ったやつ誰や出てこい
      • 1p「はいぼくです」
  • 各フレームワークの比較
    • symfony: 機能フレームワークの設計フレームワーク
    • CakePHP: いますぐ使える設計済みの骨組み
    • Laravel: 何をするにも使える設計を楽しむフレームワーク
    • どのフレームワークが良いかではなく本質を見極めて使うべし
  • 実はPHPは学びの多い言語
    • 言語、多様な思想を考えよう

Slim Frameworkで始めるPHPのmiddleware

  • middlewareってどういうもの？
  • Webアプリケーションの前段のフィルターという発想
    • Webアプリケーションの前や後にフィルターを通せる
  • Node.jsのExpressが元祖
    • routing
    • middleware
      • ルーティングの過程で任意の処理を差し込むための仕組み
    • app.get(‘/’, auth, logger, function())
      • authを通ってloggerを通ってfunctionが動く
      • アプリケーションを複数のmiddlewareでくるむ入れ子状態
  • StackPHP
    • セッションや認証を通ってアプリケーションに行き着く
  • Slim3
    • PSR-7、middleware、DI
  • middleware
    • 関数の書き方とクラスの書き方がある
    • DIコンテナと組み合わせてもっと便利に
      • インスタンス生成はDIコンテナの責務
    • __invokeメソッドがあれば良い
    • PSR-15: HTTP Middlewares(Draft)
      • MiddlewareInterface
      • DelegateInterface
    • middleware流儀
      • Double Pass: リクエストとレスポンスを受け取る
      • Single Pass: リクエストのみを受け取る
  • 他のフレームワークのmiddleware
    • laravel
      • PSR-15は意識してない
      • 従来のcontrollerの補助的な役割
    • CakePHP
      • 実装はSlimとほとんど同じだけど…
      • クラスではなくインスタンスを渡す
    • Symfony
      • Filterがベース
  • 処理をmiddlewareに任せるとテスト容易性が高くなる
  • よく使ってる処理
    • sessionやauthはもちろん
    • validationはmiddlewareに任せる
      • Requestを受け取ってるからいくらでもこねられる

今すぐできるLaravelフレームワーク！～業務アプリ開発～

  • laravelって何？を思想から読み解く
    • web職人のためのフレームワーク　と、書いてある
    • 表現に富み簡潔に楽しく創造的な仕事＝3E1Cな開発
    • アーキテクチャに専念できる
  • laravelで何を作りますか？
    • お題：業務アプリ 生産管理、在庫管理、販売管理など
    • 入力業務の増大化で複雑化をもたらす
      • Validation機能
      • この機能が強ければ強いほど安定する
  • LaravelのValidation
    • ‘required | unique:posts | max:255’
      • 簡潔で分かりやすいvalidation
      • バリデーションとメッセージのパートが分かれている
      • 他のフレームワークと違って横に延びるルール
      • ルールが多くなった時にも可読性を維持できる
      • デフォルトのバリデーションルールが40種以上ある

ひたすら楽してPHPアプリをコンテナ運用

  • 楽をしないと危険な状況に陥ることもある
  • 開発環境と本番環境の乖離があるとつらい
    • このあたりのツラミをコンテナを使って解決したい
  • 動作確認やテストをコンテナで実行するように作り変えた
    • 環境ごとの違いは環境変数で指定する
  • LaraDock
    • Laravelでコンテナ使って開発するには使うといい
    • Composerが入ってるだけだから別のフレームワークでも使える
  • コンテナ運用の標準形
    • コンテナの稼働状況を問い合わせる、デプロイ作業を依頼する
    • マネージャインスタンスがコンテナの起動・停止・入れ替えを指示
    • ホスト内のエージェントが処理を行いデプロイ状況を通知する
    • コンテナホスト郡は自分で構築する必要がある
      • docker swarmモード
      • Kubernetes コンテナ管理ツール
  • ECSを使うとうまくいく
    • ECR
      • コンテナのイメージを格納するプライベートなレジストリ
    • タスク
    • クラスタ
      • サーバは単純にアプリケーションを動かすためのリソースを提供
    • サービス
      • リソース状況をみてコンテナの実行・運用を包括的に管理
  • GitLab CIで更に楽になる
    • マージしたらテストして開発環境を更新
    • タグ付けしたら本番環境にデプロイも自動化

PHPでもサーバーレスしたい

サーバーレスアーキテクチャ

  • バックエンドの監視が面倒なので丸投げしてアプリ開発に専念しよう
  • サーバーを意識しないでよくて簡単にスケールする
  • 使った分だけ課金なのでシステムが眠ってる間にお金がかからない
  • ユースケース
    • SPA
    • モバイルアプリのバックエンド
    • IoTバックエンド
    • ストリームプロセッシング
    • チャットボット
    • バッチ処理
    • 運用の自動化
  • バッチ処理・運用の自動化をサーバレスするのが最初に試すのにオススメ
  • ServerlessといえばLambda
    • PHPは！？PHPはまだ！？

Azure functions

  • PHPで書ける
  • めっちゃ安い（月100万実行は無料？）
  • トリガーとバインディングが豊富
    • トリガー：Twitterの新しいポストのフックとか
    • バインディング：Twilio、SendGridと連携が簡単
  • Visual Studioを使ってデバッグができる
  • どんな機能があるか
    • function proxy
      • APIGatewayみたいなもの
    • デプロイメントスロット
      • Blue−Greenデプロイが簡単
    • Console
      • そのままコンソールが叩ける
    • Application Insite
      • アプリの挙動を可視化
    • Durable Functions
      • 複数のFunctionの連携を比較的簡単に実装できる
      • StepFunctionsみたいなもの
      • 今はまだα版でC#でしか書けない

Functionsの作り方

  • バインディングの使い方
    • 入力バインディングを読み込んで出力バインディングに書き込む
    • 簡単！
    • でもテストは！？
      • VisualStudioでテストできるよ
      • Macは！？
        • 「…」

まとめ

  • バッチとか重い処理をさせるにはとても便利
  • PHPで書けるのは楽
  • Durable Functionsは期待大
  • 課題
    • Serverless Frameworkでデプロイしたい
    • httpTriggerは従量課金プランだとツラい

LT

天高くそびえ立つ巨塔によってPHPをJavaScriptに変換する

  • babel
    • 任意のテキストをJavaScriptコードに変換できる
  • PHPのコードをJavaScriptコードに変換できた
    • namespaceもfile_get_contentsも動かない
    • つらい

staticおじさんになろう

  • 難しかった事例を寄せ集めただけ
  • あるメソッドの引数・返り値を変えたい
    • call_user_funcで関数を呼んでたりする
    • DIコンテナでインスタンス生成と実行箇所が分かれている場合がある
    • PhpStormのRefacrot機能が優秀
  • 過去の遺物へのリスペクトもリファクタリングは大事だよ
  • ちゃんと設計、しよう！

テスト実行速度を改善してお金をかけずに開発スピードをあげる

  • 2017年のPHP開発
    • PSR当たり前
    • composer当たり前
    • テスト格の当たり前
    • CI回すの当たり前
  • CIのテスト実行を早くしたい
  • テスト自体を早くできるようにする
    • アサーションを必要な時に必要な分だけにする
  • setUp, tearDownを使ってテストケースのプロパティを開放する

フレームワークの上でも考慮したいセキュリティのポイント

  • フレームワークのレールに乗れば楽に安全にプログラムが書ける
  • hiddenは見える、改ざんできる（信用してはいけない）
  • 仕様上のバグ
    • 認証・認可のバグ
      • 外部入力地にユーザIDや権限を持たせない
      • つねにDBや権限をチェックする
    • 利用方法のミス
      • ホワイトリスト・ブラックリスト・フォーム改ざんチェック
    • なりすまし

evalこそパワー

  • 文字列をコードとして実行する言語構造
  • 非常に危険な言語構造です。使うことはおすすめしません。（公式）
  • 危険≒つよい（確信）
  • おしゃれ危険ライブラリ
    • evalしたら速くなった！すっごーい！
  • PHPカンファレンス東京 10/8

Web APIを理解する

  • SPA作るときとか
  • REST APIはHTTPメソッドなどWebの制約に合わせる
  • 推奨設計
    • リソース部分は目的語の複数形にするのが好ましい
      • できるだけ短く利用者に分かりやすい名前をつける
    • 結果に見合ったレスポンスコードを作る方がいい
      • 400番台はクライアントに問題がある
      • 500番台はサーバに問題がある

元記事はこちら

「PHPカンファレンス関西2017に行ってきました」