Giftmall Inside Blog

株式会社ギフトモールのいろんなことを発信するブログです。

PHP Conference Asia 2018 in シンガポールで PHP 作者の話を聞いてきました

こんにちは。 Luche Holdings の藤原です。 弊社は日本とシンガポールに拠点があり、私は現在シンガポールで勤務しています。

シンガポールにて9月26日から9月29日までPHP Conference Asiaという PHPコミュニティのカンファレンスがあり、参加してきました。 今回のエントリでは主にカンファレンスの様子をご紹介させていただきます。 海外のPHPコミュニティの様子等何かの参考になれば幸いです。

概要

PHP Conference Asia はシンガポールの PHPコミュニティが中心となって開催しているカンファレンスです。 これまで2015年、2016年と開催され、2018年で3回目のカンファレンスです。

  • ホームページ: https://2018.phpconf.asia/
  • 日程:
    • 2018年9月26日: ワークショップ
    • 2018年9月27日 - 2018年9月28日: カンファレンス
    • 2018年9月29日: ワークショップ
  • 会場:
    • カンファレンス: シンガポール国立大(NUS)
    • ワークショップ(9/29): Singapore Polytechnic (Polytechnicは日本の高専のような教育機関です)

今年はPHP作者であるRasmus Lerdorfさん、PHPUnit作者のSebastian Bergmannさんといった第一線で活躍しておられる技術者の方がSpeakerとして登壇されました。

参加者の内訳としては、東南アジアだけあり、 シンガポールとその周辺地域(マレーシア・インドネシア・インド・フィリピン、ベトナム、香港)の参加者が多数でした。 Keynote Speakersをはじめ発表者の方は欧米・オーストラリアからの参加者がかなりの割合を占めていました。 また、日本からは、EC-CUBEに関する発表をされた方がいらっしゃいました。

私はカンファレンスと9/29のワークショップに参加しました。 (以下、特に断りのない限りワークショップは9/29のワークショップを指します)

会場の様子

カンファレンス会場の様子を写真でご紹介します。

f:id:fujishoichi:20181022231710j:plain:w650
会場の建物

f:id:fujishoichi:20181022232430j:plain:w650
ロビー

f:id:fujishoichi:20181022232517j:plain:w650
カンファレンスルーム

f:id:fujishoichi:20181022232516j:plain:w650
Keynote Speech

全体的な印象

  • 日本人に限らずアジア人は基本シャイのように感じました。(英語に自身がない人がシャイ、ということかもしれません)
  • 実際に手を動かしてついていくことができたのでワークショップは英語が不得手であっても有益でした。
  • PHPフレームワークとしてはLaravelを使っている参加者の方が多かったです。
  • 非同期IOやReactive Programming等のプログラミングパラダイムをPHPで実装するトピックが多かったように思います。
  • 東南アジア圏からの参加者には大学生などの若い方が多かったです。

カンファレンス内容

カンファレンス発表は以下から視聴できます。 https://www.youtube.com/playlist?list=PLECEw2eFfW7gNcVCgaij3KHHFTTME41_Z

ここでは、私が特に面白いと思った発表について内容を紹介していきたいと思います。

Opening Keynote - PHP IN 2018

PHP作者のRasmus Lerdorf さんのセッションでした。

1990年代、PHPがテンプレートシステムとして生まれて プログラミング言語に発展していく過程の話を振り返ってから PHP 7.3の新機能、性能改善の内容を紹介してくれました。

PHP 5系から7系で大きな性能改善がありましたが、 その後も性能改善を積み重ねてWordPressを題材にしたベンチマーク結果で PHP7.0/7.1からみれば10-15%程度(PHP7.2からも数%)の改善をしているとのことです。

また、PHPソースをOpcodeにコンパイルする際の最適化技法の一つであるDEC(Dead Code Elimination)を紹介してくれました。

そして、静的解析ツールとしてPhan、プロファイラとしてPHPSPY の紹介とデモをしてくれました。

スライドはこちらから閲覧できます。

(筆者所感) 当初PHPをテンプレートエンジンとして作ったのがユーザのニーズに応える形で サーバサイドのビジネスロジックを書けるように進化していく過程の話は、いかに将来が予測できないかを示すいい例だと思いました。 Rasmusさんが意図していたかどうかはわかりませんが、 結果としてリーンスタートアップで述べられているような成長サイクルをたどってPHPは発展してきた印象でした。 改めて、早くプロダクトを世に問うことの大事さを考えさせられました。

PHP - The journey so far (and what's ahead)

こちらのセッションは会場からの質問に答えていく形式のパネルディスカッションでした。 スピーカは以下の3人の方々。

  • Rasmus Lerdorfさん(PHP作者)
  • Sebastian Bergmanさん(PHPUnit作者)
  • Derick Rethansさん(XDebug作者)

(以下、敬称略)

いくつか面白いと感じた質疑応答を紹介していきます。 (日本語は私の意訳です。)

Q. PHPは過去の言語といいPHPを軽く見ている人々に何かコメントはありますか? 次の10年でPHPに何を展望しますか?

Rasmus: もちろんPHPは過去の言語です。我々はこれを25年間使ってきました。 ただし、それはもはや役に立たないということではありません。 PHPが生き残ってきたのには理由があります。 PHPがワークしないツールだったら25年間生き残っていません。 ワークしないツールをそんなに長くの間キープしないでしょう?

ギークな人の中には、 「最新であることがもっとも輝かしく、広く使われ出すともはやクールではない。PHPの世界にはそんなクールでないことがたくさんある」 と考える人もいるでしょう。

重要な事実として、PHPの利用は過去25年間決して減ったことがありません。 PHPが動いているサーバの絶対数は増え続けています。 パーセンテージでみると、大規模なISPがPHPを採用するかによって少し増えたり減ったりしますが、 それを除けばPHPを使っている人の絶対数は一様に増え続けています。

この質問に対する答えとして、他にどういえばいいのかわかりませんが、市場は市場自身を物語るということです。 もし質問にあるような評価が正しいのだとすれば、 PHPの利用は10年前、20年前に落ち込み、生き残っていなかったはずです。 しかし、PHPは生き残っています。それが、PHPとそのエコシステムについて本当にただ一ついえることです。

私は、これは一つの事実からきていると思います。 認めるべきこととして、PHPはそれほど美しい言語ではありません。 しかし、webの問題を解決していく方が、あなたの使う言語の構文がいかに美しいかよりもはるかに重要です。 言語の構文の美しさはともすればもっとも重要性が低いです。 また、エンドユーザのことを考えてください。 彼らはコードがどうなっているかを気にしません。 彼らは使っているサイトが動いて欲しいのです。 彼らは動くプロダクトが欲しいのです。

言語の構文の美しさを気にしているのはお互いに言い争っているギークたちだけなのです。 彼らが議論していることは、「タブかスペースか」等サイトが動くかどうかということに関しては無意味で全く関係ないことです。 ハンマーの色は問題になりません。 ハンマーを使って正しいものを作る、そこにフォーカスがありますし、あるべきなのです。 しかしながらギークたちはツールの色を気にします。 それは彼らがいつも気にしていることで、いつも気にしてきたことで、これから10年間も気にするであろうことです。

そいうわけで、質問の一部「PHPに対してこれから10年起きること」は、 我々はこの議論を10年間続けるということです。

「PHPは過去の言語なのか」私はこの質問を10年間受け続け、おそらく20年間受け続けるでしょう。 ただし30年間はないでしょう、そのころには私はおそらくもうこういった場にはいないでしょうから。

そういうわけで、PHPに対しては全く同じ問いをこれから10年間目にし続けるでしょう。

(筆者所感) PHPに対する批判はプログラミング言語としてのものに限らず少なからずありますが、 Keynote Speechで紹介があった通り、PHPはプログラミング言語としてではなく問題解決のツールとしてつくられたという経緯を考えると、 それはRasmusさんにとっては最重要なものではないのでしょう。 あくまでビジネス上の問題を解決できるかどうかに重きを置くことは 現実世界の問題解決に取り組むエンジニアとして私も忘れないようにしたいと思いました。

Q. PHP8はどんなものになりますか?

Rasmus: 間違いなく、高速になるでしょう。 PHP8に関してまだここで話していないもっとも主要なトピックは、おそらくJITです。 標準的なデータベースドリブンなアプリケーションはJITでそれほど早くなるとは思いません。 ただし、JITは大きな可能性を秘めていて、従来はPHP Extensionを開発しないと実現できなかったことをJITを活用してPHP本体だけで実現できるようになるかもしれません。 また、JITがあることで、C言語に必ずしも詳しくない人でもPHP Extensionを開発することができるようになるかもしれません。

その他これまでのところ議論していることとしては、ノンブロッキングIOとAsync, Fibreなどがあります。 PHP8は世の中に出るまで少なくとも2年、場合によってはそれ以上の時間がかかると見込んでいますが、 今述べたJIT、Fibre、ノンブロッキングIOが主な新機能になると私は考えています。

Derick: Syntaxに関しては、 ジェネリクスの導入を主張する声はかなりあります。 私はそれについてはあまり気にしてはいませんが、皆同じ意見(訳者解釈: ジェネリクス導入)を持っているようです。

Sebastian: 構文に関して、私が必要だと感じているのは型付きのarrayです。 ジェネリクスよりもそちらの方が必要だと私は考えています、が。。 (訳者解釈: 型付きarrayよりもジェネリクスを推す意見が強いです)

(筆者所感) JITをはじめとして、さらなるパフォーマンス改善を行なっていくとのことで、 型付けなどの機能面を強化しつつ性能をあげるのはそれぞれを独立に行うのと比べて よりチャレンジングだと思いますが、今後が楽しみです。

Q. PHPで後悔していることはなんですか?(もしやり直す必要があるならどう変更しますか

Derick: PHPをスクラッチから作り直すのなら、スタンダード関数の命名を一貫したものにできるとよいと思います。 また、おそらくオブジェクト指向を初めから取り入れるべきだったと思います。 他の後悔としては、そうですね。 DateTime Extensionの \DateTime クラスはデフォルトをImmutableにするべきでしたね。 これらが今私の考えにあることです。

Sebastian: 私が後悔していることは、PHP5のオブジェクトモデルに対する __get__set 、 そして他のマジックインターセプタの追加を推進したことです。 私がこのコンセプトに出会った言語であるSmalltalkではこの仕組みは非常にうまく動いていました。 しかし、どれだけの人がこの仕組みを濫用して、IDEや静的解析ツールで解析できず、本人も理解できないコードを書いてしまうのかを私は想像できませんでした。 私がこのことを当時知っていたとしたら? しかし、私はその当時は若く、純粋でした。そして私は周りにこのしくみを実装することを納得させることができました。

Rasmus: もし25年後に人々から問い合わせを受けることがわかっていたなら 違う実装をしたであろうことはたくさんあります。

ただ、後悔していることは、ないです。 たとえ25年後もひどいコードたちについて語ることを知った状態で 今から同じプロジェクトを初めても、後悔することはないでしょう。 なぜならPHP プロジェクトは25年も続くことを意図したプロジェクトではなかったからです。 PHPは、私が当時のクライアントのためにWebページを早くつくるための私自身のためのハックだったのです。 これは、私自身のためのツールであって、皆さんのためのツールではなかったのです。 このツールがたまたま他の人にとっても便利だったとということです。

当時のPHPには多くのハックを入れました。 その理由は、ただ私が怠惰でありつつそのハックが問題を解決したからです。

いくつかのこと、例えばsafe modeの命名は失敗でした。 何かに「セーフ」と名前をつけると、ハッカーがこぞってそれを攻撃してそれが安全でないことを証明しようとします。 また、単純とは呼ばないようなことに「シンプル」と名前をつけるのも失敗でした。 なぜならそのようなことは結局最後には複雑になるのです。SimpleXMLがいい例です。 中のコードを見ると全くシンプルではありません。

こんなことはたくさんあります。 私は初期のバージョンのPHPで多くの愚かなことをしてきました。 例えば、私が関数の解決に使ったハッシュアルゴリズムは文字列長でした。 というのは、関数には名前をつけると思いますが、初めのバージョンではPHPに関数は12個しかありませんでした。 そこで、私は全ての関数に違う文字数の名前を与えることで文字列長を高速なハッシュアルゴリズムとして活用したのです。 その一方で、私はより多くの関数を追加していくことになることは予測していましたので、 ハッシュのlookupと各ハッシュフィールドに対するlinked listは最低限持たせるようにしていました。 そして、関数はリネームしてハッシュ値である名前の文字数がより広範に分布するようにしていました。 htmlspecialchars の名前が長いのは、この関数をたくさん呼ぶから他の関数と衝突させたくなかったからです。 関数名を調節することで、この関数のハッシュフィールドにはこの関数しか存在しないようにしていたのです。 明白なことですが、グローバルなシンボルテーブルには多くの関数があるので もはや我々は文字列長でハッシュはしていませんが、命名にはまだそのころの名残を残しています。

他のこととしては、様々シンボルに対するCase Sensitivityです。 当時、HTMLがuppercase、lowercaseあるいはmixed caseであるべきかという論争に 私は関わりたくありませんでした。 1990年代の初頭から半ばにかけて、それは本当に大きな論争だったのです。 そういうわけでPHPの関数名は、uppercase, lowercase, mixed caseのいずれも許容しています。 この仕様は作り直せたらと考えています。 実際、1996年のあたりだったと思いますが、本気でこの仕様を変更しようと考えていました。 しかし、当時すでにこの変更の影響をうけるであろうPHPユーザが相当数(thousands)にのぼっており、私はその変更をやめました。 そして、今や当時をはるかに超える人(millions)がPHPユーザです。 もし数千人のPHPユーザを犠牲にすることでそれを実現できるなら、素晴らしいことです。 今からでもやってしまいましょう。

Sebastian:
今はPHP-CS-Fixerがあるのでそれはすぐに直せますね。

(筆者所感) 関数がCase Insensitiveな仕様になった経緯をはじめとして、 2018年現在から見ると洗練されていないように見える仕様にも 仕様制定当時では合理的であった理由、経緯が存在したことがわかって興味深かったです。 (これは私の推測ですが、\DateTime 型がImmutableでないことも、当時は使えるメモリが今ほど潤沢でなかったことが背景にあるのでしょう。)

Keynote 2 / How PHPUnit works, why it works like that, why I wish it did not work like that, and what I'm doing about it

こちらはPHPUnitの作者のSebastian Bergmannさんのセッションした。

PHPUnitのプロジェクトの歴史を振り返り、 プロジェクトを発展させるためにこれまで取り組んできたこと、現在取り組んでいることの紹介でした。 プロジェクトを発展させるために特に重要なのがコントリビュータの獲得で、 バージョン管理システムの進化、特にGithubがバージョン管理とコミュニケーションコストという点でコントリビューションのハードルを大きく下げたことを説明しました。 その後、2018年から入ってきたコントリビュータによって重要な機能改善がされたことを紹介しました。 また、継続的にCode Sprintというイベントを開催して、参加者にPHPUnitプロジェクトへのコントリビューションの方法を伝えてコントリビュータを増やす活動をしていることを紹介しました。

(筆者所感) この講演はオープソースプロジェクトの取り組みに関する話ですが、 オープンソースに限らずビジネス用プロダクトのプロジェクトでも 新メンバーがキャッチアップするハードルを下げるのは重要なことなので、 こういったオープンソースのプロジェクトの取り組みをウォッチして取り入れるのは大事なことと思いました。

ワークショップ

各セッションに参加するにあたっての準備作業をまとめたレポジトリです。

https://github.com/phpconfasia/workshops-2018

以下、私が参加したワークショップセッションを概要だけご紹介いたします。 (公開されている資料についてはリンクも掲載しています。)

Refactoring Legacy PHP: The Complete Guide / Junade Aliさん

SOLID原則の適用を中心にPHPのレガシーコードを改善する方法について解説してもらいました。

資料: https://github.com/IcyApril/phpasia-examples

Build your own Secure Messenger in 3 hours / Ben Dechraiさん

LaravelでWhatsAppのようなEnd-to-End暗号化を行うメッセージアプリケーションをハンズオン形式で各自実装するというセッションでした。

資料: https://bendechrai.com/workshops/secure-messenger

How to contribute to PHP Docs / Pasindu De Silvaさん

実際に各自手を動かしてPHP Docs (http://php.net/docs.php) の更新パッチを作るワークショップでした。 このワークショップで私も gmp-binomialのページ を新規作成するパッチを作りました。 (リリースされているものは実際に作ったパッチから数式表現等いくつかの修正を加えてもらっています。)

さいごに

今回ご紹介したPHP Conferenceを主催したシンガポールのPHP User Groupの情報(イベント案内、メンバー等)は Meetupのグループ(https://www.meetup.com/ja-JP/sgphpug/)から得ることができます(もちろんグループ参加もできます)。 私も定期的にイベントに参加しております。 何かの機会でシンガポールにいらっしゃるときは都合が合えばイベントに出られてみるのも面白いかと思います。

また、Luche Holdingsではシンガポールを勤務地としたエンジニアの方も募集しております。 ギフトを通じて、世の中にもっともっと「幸せな笑顔」を増やす。成長著しい東南アジアのハブでそんな仕事に取り組んでみたい方をお待ちしております!

採用サイト