php-fpm がリクエストを処理しているサイクルをざっくりとまとめました。 php-fpm ワーカープロセスの生成 リクエストループ 1) リクエスト接続待ち listen_socket の生成 FastCGI リクエスト 2) リクエスト開始処理 実行PHPファイルパスの決定 スーパーグローバルへの格納 3) PHPファイル実行 4) リクエスト終了処理 PHP コード実行リソースの解放 max_requests チェック FastCGI クライアントとの通信 接続開始 リクエスト読み取り レスポンス書き込み 接続終了 さいごに php-fpm ワーカープロセスの生成 php-fpm は FastCGI リクエストを処理する SAPI 実装の一つです。いわば、PHP コードを実行する FastCGI サーバです。prefork 型となっており、nginx 等からの FastCGI リク

PHP の use 文では、クラス名や関数名、定数、名前空間などのエイリアスを設定できます。 <?php use App\Foo; use App\Bar as ABar; $foo = new Foo(); $bar = new ABar(); https://www.php.net/manual/ja/language.namespaces.importing.php この use 文は指定したシンボルにエイリアスを設定する、言い方を変えると名前空間をインポートするもので、オートロードでクラス定義 PHP ファイルを読み込むものではありません。*1 例えば、上記コードの場合、use 文の時点で App\Foo や App\Bar に対するオートロードは動作しません。 この動きを確認してみます。 use 文のみを実行 use 文でオートロードが動作するかは下記のようなコードで簡単に確かめ

2024/05/11 に玉藻公園内 披雲閣で開催された PHP カンファレンス香川 2024 にて、「PHPコードの実行モデルを理解する」を発表してきました。 発表資料 日頃実行している PHP コードがどのように実行されているかをざっくりとイメージして頂くために、PHP コードの実行モデルと、身近な SAPI である php-fpm(mod_php)と php コマンドの実行モデルをご紹介しました。 X や発表後の会話では、やはり php-fpm(mod_php) の Laravel アプリケーションではリクエスト毎に 400 ファイル以上をコンパイルしている（OPcache 未使用の場合）話の反応が多かったです。 カンファレンスのような多様な人が集まる場では、知っている人にとっての「当たり前」を共有する発表も大事だなとあらためて感じました。こういった発表もやっていきたいですね。 Tog

php-fpm の挙動を確認するために発行されるシステムコールを簡単に確認できる Docker Compose 環境を作りました。 github.com システムコール strace-php-fpm strace オプション php-fpm が発行するシステムコール例 ini ファイルの探索 nginx からの FastCGI リクエスト PHP ファイルの読み込み さいごに 参考 システムコール システムコールは、php-fpm のようなユーザプログラムが、ファイル操作やネットワーク通信、プロセス制御のようなカーネルが提供する機能を利用する仕組みです。PHP コードは PHP（ここでは php-fpm）で実行する必要があるので、php-fpm が発行するシステムコールを確認することで php-fpm や PHP コードがどのように動作しているかを知る手掛かりになります。 システムコールを

PHP 8 の新機能の一つ、Attribute の形式が紆余曲折ありながら最終的に #[] となりました。実用上は #[] 形式だけ覚えておけば良いのですが、シンタックスの変遷は興味深いものだったので残しておこうと思います。 Attribute Attribute 仕様の変遷 8.0.0alpha1: <<>> 8.0.0alpha2 8.0.0beta1: @@ @@ の問題 8.0.0beta4: #[] #[] の注意点 さいごに Attribute PHP 8 の Attribute は、他のプログラミング言語によくあるアノテーションです。クラスやメソッド、プロパティ、関数に付与することで任意の処理を追加することができます。PHP では従来 Doc コメントでこれを指定する文化がありましたが、これを言語仕様として実装したものです。 <?php declare(strict_type

Laravel JP Conference にて「フレームワークとの付き合い方」を発表しました。 発表資料 Toggeter: https://togetter.com/li/1319786 フレームワークの付き合い方について、自分なりの考えをお話しました。アップしたスライドには、発表用スライドではカット部分などを含めています。 途中で、マイクが使えなくなったりましたが、地声で届く範囲だったのでそのまま続行しました :) マイクを持たないと両手がフリーになるので、身振り手振りがやりやすくて話やすくなるというのは大きな発見でした。 セッションを聞いていいただいた方、ありがとうございました。 グラレコ @kozzy0919 さんがグラレコでまとめて下さいました。ありがとうございます！ #laraveljpcon で「フレームワークとの付き合い方」を講演いただいた @shin1x1 さんに許可を

モチベーション 全体 サンプルアプリケーション コアレイヤ サービスレイヤ 口座間送金ユースケース 処理の流れ コアレイヤ サービスレイヤ コアレイヤ対象範囲 DDD スタイル 手続き型スタイル 実装アイデア レイヤでパッケージを分ける コアレイヤの範囲 ポートの種類 DDD スタイルへの一歩目 さいごに 参考 独立したコアレイヤは、アプリケーション実装パターンである。以下のような特徴を持つ。 アプリケーションを、何を実現するのか（What）と、どのように実現するのか（How）に分ける。 What は、コアレイヤに実装する。ユースケースやドメインロジックを実装する。フレームワークやライブラリには依存しない。UI やデータベースからは独立している。 How は、サービスレイヤ（仮）に実装する。フレームワークやライブラリを活用して、ユースケースが要求する技術詳細を実装する。 コアレイヤが必要な

TDD の原典である テスト駆動開発 が、t_wada さんによって再翻訳されるということで興味を持っていたところ、見本誌を送って頂きました。ありがとうございました。早速、拝読させて頂きました。 以前の翻訳版である「テスト駆動開発入門」が出版された頃、XP 本や他の xUnit 本などは読んだのですが、本書は未読でした。テストをコードで書くことや自動化には興味があったので、おそらく手に取ったことはあったと思うのですが、購入には至りませんでした。 当時は、新しい開発プロセスの一つとしてテストの自動化を捉えていましたが、それを日々の開発で当たり前に行っている中で本書に触れてみてどのように感じるかという視点で読み進めました。 本書は、三部構成となっています。第 1 部 と 第 2 部 では、TDD を実践しながらコードを書き上げていく過程を解説しています。第 3 部は、テストに関する様々な話題が

PHP カンファレンス 2017 にて「型を意識した PHP アプリケーション」を発表してきました。 発表 github.com 型宣言が付いていないコードに、スカラー型の型宣言、ドメインに特化した型の型宣言と型（クラス）の実装を行うライブコーディングをメインにしました。 ライブコーディングの部分は動画を見た方が分かりやすいです。下記の 13:00 頃からコーディングがはじめるので、こちらも合わせてどうぞ。 きっちりまとめられた資料をベースに発表するのも良いのですが、実際にコードを書いていくのを見た方がイメージも伝わりやすいですし、私自身も人がコードを書く様を見るのが好きなので、この構成にしました。 また、質疑応答の時間を長めに取りたかったので、本編は少し短めにして時間が余るように調整しました。当初の内容からどんどん引き算していって、内容をシンプルにしたので、結果的には進めやすかったですし

PHP カンファレンス関西 2017 の基調講演にてお話してきました。 発表資料 今回は、開発現場から見た PHP の特徴をあらためて見直すということで、私が日頃感じている特徴をお話しました。最後には現場で奮闘している PHP エンジニアへのメッセージを入れました。 朝一番のセッションにも関わらず、立ち見が出るほど多くの方に参加頂き、嬉しい限りでした。参加頂いたみなさん、ありがとうございました。 資料だけでは伝わらない部分もありますが、資料を上げておきます。 終わり際にある「繋ぐ言語」というのは、2014 年基調講演された郡山さんの「全てを結ぶ力」へのオマージュだったりします。発表後に会場でご本人に伝えるとがっちり握手して頂けました :) 基調講演 これまで、招待講演も基調講演を招く側も経験していたのですが、基調講演で話すというのは初めての経験でした。 はじめは、いつもの発表のノリで軽く受

PHPの現場 にて、DI 談義を行うので、頭を整理しておくためのメモです。 DI についてきちんと知りたいのであれば、参照に挙げたリンク先に有用な記事があるので、そちらを参考にして下さい。 PHP を念頭に置いてますが、Java など他言語でも大枠は同じだと思います。この内容は、いずれ整理するかもしれませんし、そのままかもしれません。 DI という言葉 「DI」が差す意味合いが、依存オブジェクトの注入だけなのか、DI コンテナによる注入を含んでいるのか、DIP まで意識しているのかが、人やコンテキストによって違っていそうで、そこを揃えてから議論しないと。— Masashi Shinbara (@shin1x1) May 19, 2017 DI について話す時に、何を差すのかが異なると話が噛み合わない。そこで、それぞれに名前を付ける。 DI パターン = 依存オブジェクトを注入することを差す

学生の頃からラジオを聞いて育ってきたので、技術系のPodcastが好きで色々と聞いています。 日本語で PHP 界隈の話題について話すPodcastが無かったので、はじめてみることにしました。 「PHPの現場」というPodcastです。 PHP がメイントピックにはなりますが、PHP の開発現場で出てきそうな話題なら、それ以外の技術や話題についても扱っていくつもりです。 私がお話したいゲストの方をむかえて対談（雑談）形式でざっくばらんに話していきたいので、色々な方にお声がけしていこうと思います。その際は、よろしくお願いしますm(_ _)m Podcast配信環境 Podcastを配信する上で、どうしようかと迷ったのは配信環境です。 SoundCloud などのサービスを利用することも考えたのですが、どうせなら作ってしまおうと思い、自作しました。（実は、過去にPodcastの配信を行ったこと

例外をどのような状況に投げるかもしくは投げないか、というのはわりと意見が分かれるところです。もちろん、プログラミング言語によっても異なりますが、同じプログラミング言語ユーザ同士でも様々です。 基本の考え方 ベースとしては、Effective Java の項目 39 にある下記の方針が参考になります。 例外的な状況の時にのみ例外を使う。 Effective Java 禅問答のような定義ですが、これには異論は無いでしょう。例外を正常フローで利用したり、制御構造に用いるべきではありません。 人によって異なるのは「例外的な状況」の解釈です。 例外的な状況 この「例外的な状況」の解釈は人によって異なるようで、これまでも議論になっていました。これまで聞いた解釈を乱暴に分けると以下の 2 パターンに分かれます。 1. アプリケーションから独自の例外を投げる派 ランタイムやミドルウェア連携などプラットフォ

2016/11/03 に開催された PHP カンファレンス 2016 にて、「正規表現再入門」を発表してきました。 資料 speakerdeck.com togetter.com 内容は、正規表現のマッチングの動き、量指定子のマッチングパターン、バックトラックやパフォーマンスへの影響についてです。 下記のエントリを下地にして、マッチングの動きを分かりやすく伝えることを意識してお話しました。 blog.shin1x1.com 参加された方からは、「分かりやすかった」といった好意的なフィードバックを頂けたので、発表して良かったです。 これから正規表現を学ぶにしても、マッチングがどのように行われるかをざっくりと知っておけば、正規表現を書く際にも動きが想像できるので、この発表がお役に立てると嬉しいです。 偶然、同じ時間帯に発表があった徳丸さんのセッションでも正規表現に触れられていたようで、Twit

2016/10/19 に大阪で開催された Laravel Osaka 2016 にて、「DDD パターンを活用した Laravel アプリケーション開発」を発表しました。 会場の MOTEX さん。巨大スクリーンが 2 面あり、話しやすい環境でした。 発表資料 Laravel の具体的なテクニックに比べると抽象的な内容なので、どれだけ伝えられるか思案したのですが、聞いて頂いた方からのフィードバックや参加者アンケートでも概ね良い評価を頂けたので安心しました。 ValueObject については、さらに掘り下げて話せるテーマなので、これ単体でもまた話してみたいです。 Value Object は基本ですね | DDDパターンを活用した Laravelアプリケーション開発/ddd-with-laravel https://t.co/ZzRTnt0tY6— 増田 亨． (@masuda220) O

HTTP リクエストに任意の値をセットすることで、Web アプリケーションからの HTTP 通信を傍受したり、中間者攻撃（Man-in-the-Middle）を可能にする脆弱性が見つかっています。 専用サイト httpoxyという名前が付けられ、専用サイトが立ち上がっています。詳細は、このサイトが詳しいです。 httpoxy.org 攻撃内容 アプリケーションからHTTP通信を行う際に、環境変数HTTP_PROXYの値を、HTTPプロキシとして見るライブラリがある。 HTTPリクエストにProxyヘッダを付けられると、環境変数HTTP_PROXYにその値がセットされる。（これは、CGIの仕様） つまり、任意のプロキシを外部から指定できてしまうので、通信内容の傍受や偽装ができてしまう。 対象となる PHP アプリケーション HTTP リクエストを受けて動作する PHP アプリケーション アプ

DDD 関連の書籍といえば、Eric Evans の DDD 本（ エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) ）や、Vaughn Vernon の IDDD 本（ 実践ドメイン駆動設計 (Object Oriented SELECTION) ）が有名です。 DDDで登場する実装パターンや周辺知識をより実践的に解説しているのが、「．ＮＥＴのエンタープライズアプリケーションアーキテクチャ　第２版 (マイクロソフト公式解説書)」（naa4e）です。 .NET 以外にも大いに通じる内容 本書は、.NET の名を冠しており、サンプルコードは、C# で記述されています。また、利用するライブラリも .NET 周辺のものであったり、解説で登場する RDBMS も、Web 系でよく登場する MySQL や PostgreSQL よりも、S

勉強会や技術系のイベントで色々な発表を聞いていると、せっかく勇気を出して壇上に立ったのに、ちょっとしたことでもったいなあと感じることがあります。これは特に、発表に慣れてない人に多く感じます。 本エントリでは、大いなる自戒を込めて、発表慣れていない人へこの辺を気をつけるともっと良くなるよ、というポイントを挙げてみます。 なお、下記のポイントは、発表慣れている人や意図してやっている人はスルーして下さい :) 1. 自己紹介が長い LT の時に感じるのですが、発表時間が 5 分しかないのに、自己紹介に時間をかけるケースがあります。自分が何者か伝えるのは大切ですが、自己紹介より発表内容が大事です。また、聞いている側からすると数多くの発表者の中の一人なので、よほどインパクトがある自己紹介でないと、あまり覚えていなかったりします。（それより内容の方が記憶に残りやすい。） やはり内容が大事で、そこが聞き

2016/02/26 に出版される「サーバ/インフラエンジニア養成読本 DevOps編」というムック本にて、Ansible 2 について書きました。 本書は、昨今では普及してきた DevOps や Infrastructure as Code といったキーワードに関心がある方向けの本です。はじめに概念の定義や現状をおさえた後に、Ansible、Circle CI、Docker、Kubernetesなどツールを活用して実践する構成となっています。 Ansible 2 によるサーバ環境の構築 特集 1 である「Ansible 2 によるサーバ環境の構築」を担当しました。ここでは、Ansible の基礎をベースに、Vagrantを利用したサーバ環境の構築を解説しています。 Ansible には多くのユーザがおり、すでに多くの Playbook が公開されています。そこで、Playbook のシン