user
Shun Namiki

Freelance full-stack Endigneer @ Shibuya, Japan

Published on Dec-15th, 2018 ( 10 min read )

【まとめ】PHP Conference 2018 | カンファレンステーマ『Growth』とPHP離れの現実

PHP Conference 2018 - #phpcon2018 に行ってきたのでそのまとめ。

🗒目次

🙌Opening(原田 裕介 / 日本PHPユーザ会)

  • 今回のカンファレンステーマ「Growth」からジュニアエンジニアの育成に力を入れる

🚀PHPのいまとこれから 2018(廣川 類 / 日本PHPユーザ会)

👤SEPEAKER

💬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

💬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

💬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 タグ

arrow_back

Previous

Netlify + Netlify CMS + GatsbyJS ( React + GraphQL )でブログ作ったときにハマった点

Next

【まとめ】日本をぶち上げるiNTERFACE SHIFT2018 | エンジニア目線のキャリア戦略の学び
arrow_forward