【まとめ】PHP Conference 2018 | カンファレンステーマ『Growth』と PHP 離れの現実
PHP Conference 2018 - #phpcon2018 に行ってきたのでそのまとめ。
🙌Opening(原田 裕介 / 日本 PHP ユーザ会)
- 今回のカンファレンステーマ「Growth」からジュニアエンジニアの育成に力を入れる
🚀PHP のいまとこれから 2018(廣川 類 / 日本 PHP ユーザ会)
👤SEPEAKER
- by @rui_hi
💬SESSION
- 12/8-7.3-Release
- 7.0 以前が EOL になり利用ユーザの約 80%が取り残される。セキュリティ関連のアップデートされないので、頑張って上げていってほしい。
- Hack の今後の方針として、ユーザ数を増やすところではなく機能と増強していくことに注力していく
- 【7.4 で入る見込みの仕様 ① プリロード】今の仕様ではコンパイルされるタイミングで OPCODE のキャッシュされるが、OPCODE がプリロードできるようになると Web サーバ起動時に読み込まれる
- 【7.4 で入る見込みの仕様 ②Typed Properties】 グローバル変数にて型指定ができるようになる
📝 まとめ
- 7.3 の新機能などの仕様の説明・整理などと今後の 7.4 でのメインで改修される内容についての話だった。
- 先日リリースされた PHP7.3 の changelog から軽度なアップデートな印象だったが、今回の発表の説明を聞いた内容からも同様の印象だった。
- 次回の 7.4 ではプリロード・TypedProperties など、よく使われるであろう実装へのポジティブな影響があるので楽しみになる内容であった。
🚀 独立したコアレイヤパターンによる PHP アプリケーションの実装(新原 雅司 / 1 × 1株式会社)
👤SPEAKER
- by Masashi Shinbara(@shin1x1)さん | Twitter
- blog: 独立したコアレイヤパターン - Shin x Blog
- repository: shin1x1/phpcon2018-independent-core-layer: PHP カンファレンス 2018 独立したコアレイヤパターン
💬SESSION
- MVC
- M か C が Fat になる。
- 昔なら C よりは M を Fat にするほうがよいとされている。
- MVC + Service
- Service レイヤーにドメインロジックを記述して MVC から分離する。が、Service げの分離は完全には出来ないケースが多い
- レイヤードアーキテクチャ(DDD)
- 分離はできるが複雑になるため、オーバーアーキテクチャになるケースが多い
- 独立したコアレイヤパターン ★
- ベースアイデア
- What と How を分離
- ロジックと FW の分離
- シンプルであること
- 2つのレイヤに分離。「コアレイヤ」と「アプリケーションレイヤ」に分離
- !()[https://cdn-ak.f.st-hatena.com/images/fotolife/s/shin1x1/20180510/20180510235928.png]
- 【① コアレイヤ】ドメインロジックを PlainPHP で実装し、依存関係逆転の原則(DIP)を使ってアプリケーションレイヤーからコアレイヤへ依存させる
- 【② アプリケーションレイヤ】FW・ライブラリにて外部とアクセスする
- 実際にやった結果
- どちらのレイヤーに分けるかは迷うこともあるが、Plain・FW で別れているので、そこのジャッジで分けられる強みがやはり大きい
- ベースアイデア
📝 まとめ
- レイヤードアーキテクチャ・オニオンアーキテクチャを更にライトにしたアーキテクチャという印象
- MVC アーキテクチャ経験者がレイヤードアーキテクチャをやってことがないときのファーストステップとして導入するのは良さそう
- レイヤードアーキテクチャ経験者がオーバースペックなアーキテクチャの解消として選定するのは良さそう
🚀PHP,Go,Elasticsearch による、@cosme を 5 倍速くする取り組み (R&D 部チーフエンジニア 久保田 賢二朗 / 株式会社アイスタイル)
👤SPEAKER
💬SESSION
- 「モノリシックかつ10年以上運用かつ仕様が誰もわからない」という状態から、刷新して、Phalcon / goa / ElasticSearch を使用。
- リグレッションテストでは、DOM を前後で比較するツールを作成して実現
📝 まとめ
- 既存システムをモダンな技術スタックで刷新した話で、リプレイスに伴う切替時に起こる問題点や改善点をまとめられていた
🚀PHP での gRPC クライアント作成とユースケース(村上 俊介 / Chatwork 株式会社)
👤SPEAKER
💬SESSION
- PHP で gRPC サーバの実装は現実的ではない。なぜなら php-fpm が gRPC を解釈できないのでコア機能の Stream が使えない。そのため、PHP で gRPC のクライアントを作成した。
- [Browser]->[PHP]->[gRPC Server in go]->[Scala]->[DB Layer]
📝 まとめ
- 話を聞いている限りは gRPC と PHP で相性が悪そう。
- IDL を導入したいだけなら Thrift は PHP を対応しているはずなのでそちらでも良かったのではないかと思った。
🚀PHP と Apache Spark で始めるデータ解析処理 (竹澤 有貴 / 株式会社アイスタイル)
👤SPEAKER
- Yuuki Takezawa@ytake(@ex_takezawa)さん | Twitter
- PHP と Apache Spark で始めるデータ解析処理 / php-with-apache-spark - Speaker Deck
- Laravel conference 2019 の実行委員長
💬SESSION
- ApatchSpark とは分散処理を行う FW(PHP では実装出来ない)で DB とは別物。利用場面は「大量データをリアルタイムに」「マイクロサービス」「すでに Hadoop などの環境がある。」という場面なので、一般的にはあまり利用しない
- 分散クエリエンジンとして複数 DB からのデータ取得などを同一ランタイムで行える
- データ分散処理では同一 DB への READ・WIRITE はしないで、CQRS がベースになり、それぞれの専用の DB を作成する形が基本になる。ロックする可能性が発生してしまうため。
- HIVE:分散クエリエンジンのラッパーでクエリベースで簡単に取得できる
📝 まとめ
- めちゃくちゃわかりやすい発表内容だったこともあり、自分で勉強してハンズオンで始めれば構築できるのではないか?と思わさせてくれるような内容だった
- 分散処理や分散データベースを扱うだけのシステムに携わる経験は個人開発や小規模サービスでは出来ないので、こういったカンファレンスで知見を展開してもらえるのは特にありがたい。
💔PHP 離れに伴う PHP-Conference への影響
縁あって中の人と 2h くらい会話して内部事情を聞けた
- PHP から Go などの他言語にリプレイスするケースがかなり多く PHP 離れが多い。特に、古いシステムの場合はバージョンアップしていく工数がデカイので刷新されやすい。
- 古参の PHPer は居るが若手エンジニアの参入が減ってきているので、若手エンジニア参画を考慮してセッションのレベル感を調整している
🎉 総括
- 初学者向けのセッションと一般的・中上級者向けのセッションとレベル差がかなり広くて存在していたこともあり、どのセッションを聞くかの選定はきちんと事前に行わないと激しいミスマッチが起こる可能性が高かった。
- 言語特色として年齢が高いシステムである前提あるケースが多いため、発表内容も「技術的負債とどう付き合うか?」「既存システムからのリプレイス知見」などが多い印象だった。
- カンファレンス維持の為にレベルの高いセッションだけでなく入門者向けのセッションも意図して採用しているので経歴・登壇者経験が浅い人は狙い目かもしれない
- 7.0 以前が EOL になり利用ユーザの約 80%が取り残される。これに伴いバージョンアップを迫れるが、言語を変えてリプレイスする可能性も合わせて上がるので PHP 離れが加速してしまう恐れがある状況となっている。
- 緩やかかな衰退が始まっている今の状況は昔の Perl・COBOL のように案件が減っていく可能性があるようにも感じる。とはいえ、今から開発を行う場合でも技術選定を行った上で PHP を採用するメリットはまだまだ大きくある状況なのは変わらない点や、個人的に PHP に思い入れがある点からも是非 GROWTH していいって欲しいという思った
Twitter タグ