Skip to content

ぶっちゃけどうなのPHP

公開日:

福岡県福岡市福岡ファッションビル・FFBホールで開催された『PHPカンファレンス福岡2025』でレギュラーセッション(30分)として発表しました。

Download PDF

スライドテキスト

Page 1

ぶっちゃけどうなのPHP

Honestly, What's the Deal with PHP?

pixiv Inc.
USAMI Kenta

2025-11-08 #phpcon_fuk

PHPカンファレンス福岡2025

Page 2

お前誰よ

  • うさみけんた (@tadsan) / Zonu.EXE / にゃんだーすわん
  • ピクシブ株式会社 Platform Div > WebTechnology Team PHPer
    • 2012年末から現職、APIとかCIとかいろいろなところを見つめてきました
    • 最近チームが再編されてインフラっぽい仕事もしてます
  • Emacs PHP Modeを開発しています (2017年-)
  • プログラミング言語にちょっとこだわりのある素人 (spcamp2010)

Page 3

今回のお題

Page 4

<?php

Page 5

PHP… ぶっちゃけどう思う?

Page 6

おぼろげながら浮かんできたんです

C#… ASP.NET…

Node.js…

Rust…

Common Lisp…

Go…

Java…

Python…

TypeScript…

Ruby on Rails…

Smalltalk…

Swift…

Kotlin…

Page 7

いろいろな選択肢が
あるのに我々は
PHPにしがみつくのか

Page 8

個人的には楽しい
言語をいろいろ
選んできた

Page 9

俺 vs プログラミング言語

  • 2005-2009: PHS(携帯電話)でぽちぽちHTMLとJSを書いてた
  • 2010: 札幌でRubyコミュニティに出入りしてた
    • この頃からプログラミング言語論とか言語処理系に興味を持つ
  • 2011: 札幌でPython勉強会に参加したり、F#を教わる
  • 2012: 東京に引っ越してRubyKaigi, Shibuya.rbなどに出入り
  • 2016-: PHP系のカンファレンス発表、Emacsのイベント運営

Page 10

仕事では12年くらい
登壇は9年くらい

Page 11

プログラミング言語と Webとフレームワーク にこだわりのある人間

Page 12

アジェンダ

  • 前PHP時代 〜 Rasmusは何を革命したのか
  • Webフレームワークの中世期断絶
  • PHPが往かなかったWebフレームワークの世界線
  • 非同期I/OとWeb

Page 13

話は
1993年に さかのぼる

Page 14

出典: フリー百科事典『ウィキペディア(Wikipedia)』より引用
https://ja.wikipedia.org/wiki/ラスマス・ラードフ

2021-07-01T14:10:55版

Page 15

出典: 伝説のPHP作者「Rasmus Lerdorf」名言集を聞くと嫌PHP厨がファビョる

https://web.archive.org/web/20100501140915/http://anond.hatelabo.jp/20100427231539

Page 16

出典:伝説の喫煙者「黒木 灰次郎」名言集を聞くと嫌煙がファビョる

http://blog.livedoor.jp/hokanisurukotoha/archives/1121714.html

Page 17

出典: ウィキクォート https://ja.wikiquote.org/wiki/ラスマス・ラードフ

Page 18

PHPは多くの人から疎まれ、
まじめなプログラミング言語として
考察対象とされていない節がある

Page 19

出典: IT Conversations | Rasmus Lerdorf | PHP on Hormones

https://web.archive.org/web/20130729204354/http://itc.conversationsnetwork.org/shows/detail3298.html

Page 20

Rasmus LerdorfはMySQLとPostgreSQLの両方に 導入されているSQL標準(ANSI92 SQL)を無視した
mSQLのLIMIT句のオリジナル作者です

出典: IT Conversations | Rasmus Lerdorf | PHP on Hormones

https://web.archive.org/web/20130729204354/http://itc.conversationsnetwork.org/shows/detail3298.html

Page 21

Page 22

Page 23

Page 24

Page 25

CGIとは何か

  • Common Gateway Interfaceの略、1993年頃に登場
    • HTTPサーバを独自実装しなくても、シンプルなスクリプトを書くだけで
      動的ページを実現できる
    • ユーザーからリクエストが来る度にプロセスを起動する
      • シェアードナッシング (並行して処理するリクエストと干渉しない)

Page 26

CGIとプログラミング言語

  • 仕様上、標準入出力(stdio)と環境変数が使える言語ならなんでもいい
  • 開発の利便性などから、Perlスクリプトが普及した
    • 文字列処理のしやすさ、正規表現、cgi-lib.pl、言語としての書き心地…
      • C言語での文字列処理は本質的に難しい
  • ラスマスが重要視したのはそこではなかった
    • パフォーマンス、HTMLとSQLとの統合…

Page 27

Page 28

Rasmusは何をしたか

(〜1995年くらい)

  • パフォーマンスのため、C言語でCGIを書いた
  • 自分で書いたCGIツールに「PHP」という名前をつけた
  • CGIをやめ、Apache HTTP Serverのモジュール化した
  • ソースコードごとフリーソフトウェアとして公開した
    • Perl, Apacheなどの先例はあるが、「オープンソース」ブーム前

Page 29

1993年時点で存在したデータベースソフトウェア。
フリーソフトウェアではないがソースコードが
公開されていて、MySQLなどに影響を及ぼした。

Page 30

Page 31

Page 32

Page 33

Page 34

Page 35

Page 36

Page 37

Page 38

Page 39

Page 40

Page 41

Q. つまりPHPって
何だったの?

Page 42

A.

異常に行動力があるRasmus
さんが自分のためにPHPを作っ て、何回か書き直した後に利己的 な動機でソースコード公開したら 世界的に開発が盛り上がっちゃった

Page 43

Page 44

PHPはWebに何をもたらしたか

  • HTMLテンプレート (HTML内に制御構造や変数展開)
    • JSP(Java), eRuby/ERBなどのHTMLテンプレートに影響
    • それ以前は print "<div>Hello</div>"; のようなコード
  • CGIの代替としてのサーバーモジュール組み込みと開発者体験
    • 現代ではコンパイルが必要な言語でも「ホットリロード」が普及
  • フリーソフトウェアとして公開された言語(の先行事例のひとつ)

Page 45

第2部
Webフレームワークの
中世期断絶

Page 46

あるいは
幼年期の終わり

Page 47

コードを書くと 何らかの単位で
抽象化したくなる

Page 48

コードが増えると
バグも増える

Page 49

コードが減れば
バグも減る

Page 50

ライブラリ化
フレームワーク化
レイヤー化

Page 51

ライブラリ化

  • 処理を関数やクラスの形でまとめて呼び出せるようにする
  • ある人曰く「PHPの関数の数は、人間がWebでやりたいことの数」であると
    • 完全に同意するわけではないが、本質の一面を捉えていると思う
  • PHPの関数は外付けのライブラリに留まらず、HTTPをネイティブサポート
    • これは良し悪しあるが、セキュリティに関しては単なるCGIライブラリでは実
      現できないレベルでヘッダインジェクションの対策ができる

Page 52

フレームワーク化

  • ライブラリとの最も明確な違いは「制御の反転」
    • あなたはコードを書いてライブラリ関数を呼び出す
    • フレームワークはあなたの書いたコードを呼び出す
  • どのような規則でコードを実行するかはフレームワークの性質による
    • Webフレームワークはユーザーのリクエストによって対象を起動
    • テストフレームワークはディレクトリやファイル名によって対象を起動

Page 53

レイヤー化

  • 処理を「層(レイヤー)」に分けて整理する
  • これにはさまざまな観点がある:
    • MVC (Model-View-Controller)
    • 3層アーキテクチャ、Ports and Adapters(クリーンアーキテクチャ)
    • HTTPインフラとロジックの分離

Page 54

HTTP層のレイヤー化

  • PHPはHTTP機能を言語が直接サポートする(Server API)
    • mod_php, php-fpm, cgi, cliなどがあるが、あまり意識の必要がない
  • 他言語では従来のCGIスクリプトは廃れて、サーバとアプリケーションを
    分離するインターフェイスを定める方向にシフトした
    • Python=WSGI, Ruby=Rack, Perl=PSGI
  • GoやNode.jsも標準でHTTPサーバをバンドルしている

Page 55

Ruby on Railsの登場

  • Webフレームワーク界の風雲児・フルスタックフレームワーク
    • CoC (設定より規約): 重厚な設定が必要なFWのアンチテーゼ
      設定を書かなくても慣習通りに配置すれば勝手に呼び出してくれる
    • 多数の高機能な組み込みライブラリ:
      O/Rマッパー、ルーター/URLヘルパー、
    • 積極的なコード生成(スキャフォルディング):
      最初期は「15分でブログを作れる」と宣伝された (2005年)

Page 56

RubyにとってRailsは何を変えたか

  • Rails 1.0は独自のHTTPレイヤーで実装されていた
  • 現代のRails(Rack)アプリケーションをCGIで実行することは可能だが、
    オーバーヘッドが大きい
    • CGI時代のRubyスクリプトと、RailsのControllerクラスの実装は
      互換性がない
    • 「コード書き直し」 or 「捨てる」の二択を迫られる

Page 57

PerlとHTTPレイヤー

  • 2000年代まで「WebアプリといえばPerlでCGI」という感じだった
    • SNS以前はKENT WEBの掲示板やチャットをレンタルサーバーに置いて
      コミュニケーションをとっていた時代もあった
  • CGI時代のPerlスクリプトと、業務で開発するPerlアプリケーションの
    世界は分たれてしまった…

Page 58

PHP界への余波

  • 2004年を画期として、「フレームワーク」というものの見方が変わった
    • CakePHPは当時の機能で再現可能な範囲で最大限Railsを模倣している
      • ルーティングすら書かなくてもコントローラーが呼ばれる(!)
        • GET /users → UserController::index()
    • さらに後発のフレームワーク(Laravelなど)は、Rails風の便利さは
      残しつつも明示的に設定させることでコードの追いやすさを意識

Page 59

/data/www/www.pixiv.net (document root)
├── index.php
├── novel
│   └── show.php
├── yyy.php └── zzz.php

Page 60

NovelController#show

# routes.rb
get '/', to: 'index'
get '/n/:id', to: 'novel#show' get '/u/:id', to: 'user#show'
get '/yyy', to: 'yyy' get '/zzz', to: 'zzz'

Page 61

PHPにとってのFW

  • RailsアプリケーションはControllerを書かないと、そもそも実行されない
  • PHPにとってのフレームワークは、便利ライブラリ集と見分けがつかない
    • あるいは、お行儀よいアプリケーションを書くための拘束具に過ぎない
    • Controllerで setcookie() や header() 関数も動く(!)
      • そんなことをするとユニットテストが書けなくなってしまう!
  • PHP自体は依然としてCGI時代と地続き

Page 62

PHP以外は CGI時代との
分断・断絶を経験

Page 63

PHPは
FWが一般化後も
断絶を経験してない

Page 64

ここまでは 過去の栄光

Page 65

PHPは現在も
パフォーマンス改善
されているが、

Page 66

頭にはいろんな言語が浮かぶ

C#… ASP.NET…

Node.js…

Rust…

Common Lisp…

Go…

Java…

Python…

TypeScript…

Ruby on Rails…

Smalltalk…

Swift…

Kotlin…

Page 67

PHPよりもっと速い言語で書いた方がいいじゃん

Page 68

PHPよりエレガントな言語で再構築すべきだ

Page 69

常にさまざまな誘惑がある

Page 70

Page 71

Page 72

コードをエレガントに書き直すのは今やるべきなのか?

Page 73

高速な言語で書き直すのは今やるべきなのか?

Page 74

リソース配分

Page 75

PHPはどこでも65点を出せる言語

Page 76

…と言いたいが、PHPにも歯が立たない局面もある

Page 77

C10K Problem

Page 78

チャットアプリで結果をリアルタイムに返す

Page 79

WebSocket
Server-Sent Events

Page 80

preforkモデル(mod_php, PHP-FPM)は相性最悪

Page 81

PHPはこのまま白旗を上げるしかないのか

Page 82

Page 83

勝った!
PHP大勝利

Page 84

……とは行かない

Page 85

グローバル変数や静的プロパティがリセットされない

Page 86

CGIとは何か

  • Common Gateway Interfaceの略、1993年頃に登場
    • HTTPサーバを独自実装しなくても、シンプルなスクリプトを書くだけで動的ページを実現できる
    • ユーザーからリクエストが来る度にプロセスを起動する
      • シェアードナッシング (並行して処理するリクエストと干渉しない)

Page 87

この環境を全部捨てることになる

Page 88

Notes on Programming in C

ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。

— Rob Pike

https://www.lysator.liu.se/c/pikestyle.html

訳語はUNIX哲学 - Wikipediaより引用
(2025年10日2日12:33:03版)

Page 89

問題になっていないことを悩んでも仕方ない

Page 90

本当にPHPに不得意な仕事をさせる必要があるのか?

Page 91

本質的な問題を解決できる言語を使おう