今年11月にリリースされる予定のPHPの最新バージョン8.2における機能強化・変更点を中心にPHPの開発に関する最新の情報,PHPコミュニティに関する話題について紹介します.PHPの最新動向に興味がある方向けに,初心者の方にもわかりやすい解説にしたいと思います.
オンプレミスにて提供しているサービスをパブリッククラウドへ載せ替える際に注意しながら取り組んだ点を紹介します。
また、私たちのサービス価値を維持するため、競合との競争力を失うわけにはいきません。
そのため、パブリッククラウドへマイグレーションを行うプロジェクトと並行しながら、
如何にサービス改善を行ったかを紹介します。
さらに、EOLを向かえたWebフレームワークを利用していたため、クラウド環境に移行するにあたり、SymfonyからLaravelへWebフレームワークのマイグレーションをいかに効率的に実施したのかも合わせて紹介します。
本セッションでは、FLEXY(フレキシー)が定期開催しているオンラインイベント「CTO meetup」の出張特別編として、Makuake、BASE、pixivと国内トップクラスのサービスを展開する3社に登壇頂きます。
ユーザー数やサービス実績を伸ばし続ける3社が、安定的かつ継続的にプロダクト開発を進める上で工夫してきた点はどこか。
また、サービス拡大に伴い組織も大きく成長するなか、どのようにチームパフォーマンスを最大化させたのか。
PHPをはじめとする技術活用の手法から、外部人材活用や開発体制構築といった組織戦略の話まで、実践テクニックを語って頂きます。
Makuake
「生まれるべきものが生まれ 広がるべきものが広がり 残るべきものが残る世界の実現」をビジョンに掲げる、アタラシイものや体験の応援購入サービス。
会員数が約220万人(2022年7月時点)、Makuakeに掲載した各プロジェクトに対する応援購入総額は年間200億円規模と国内最大級の実績と人気を誇るプラットフォーム。
登壇者
CTO/生内 洋平さん
Twitter: https://twitter.com/ikunai
BASE
「ネットでお店を開くなら」でお馴染みとなっている、誰もが簡単にショップ開設できるネットショップ作成サービス。
充実した機能や使い勝手の良さから、5年連続ネットショップ開設実績No.1、累計180万以上のショップの開設実績を誇る。
登壇者
CTO/川口 将貴さん
Twitter: https://twitter.com/dmnlk
pixiv
イラスト、マンガ、小説作品の投稿プラットフォームで、今年9月にサービス開始から15周年を迎える。
昨年9月時点で登録ユーザー数7,100万人以上(うち半数近くが海外ユーザー)、累計投稿作品数1億超えという実績をもつ国内最大級のクリエイタープラットフォーム。
登壇者
開発リーダー/宇佐美 健太さん
Twitter: https://twitter.com/tadsan
PHP製の複数のサブシステムをもつWebサービスの開発運用の現場を、新卒2年目のWebアプリケーションエンジニアとSREが、2つの側面から紹介します。
Webアプリケーションレイヤにおける改善の取り組み
新しい機能開発と並行してWebサービスのレガシーな部分を継続的に改善する取り組みについて、Webアプリケーションエンジニアの側面から紹介します。
カラーミーショップの改善におけるSRE活動について
社内横断SRE組織が、カラーミーショップのエンジニアとともにWebサービスを改善するために行っている施策について紹介します。
Twitter:
やんまー: https://twitter.com/yammerjp
ほみるん: https://twitter.com/h0mirun_deux
SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。
本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。
みなさんは普段からPHPやGo, JavaScript, Java などいろいろな言語でプログラムを書いて実行させていると思います。言語によってコンパイルの様な事前作業が必要だったり、書いたプログラムの実行方法が違ったり、実行速度が違ったりしますが、その違いはどこから来ているでしょうか。そしてそもそもプログラムを実行した時にコンピュータの中では何が起きているでしょうか。
このトークではみなさんがプログラムを実行した時のコンピュータの動作を電気回路から画面表示までに分けて解説します。
このトークを通じてCPUやその他のハードウェア、コンパイラなど「コンピュータの低レイヤ」と言われる領域に興味を持ち語り合える仲間が増えることを期待しています!
2021年6月に出版された「PHPフレームワーク Laravel Webアプリケーション開発 バージョン8.x対応」の11章「テスト駆動開発の実践」を、著者自らデモを交えて解説します。TDDを始めたいけれどどうやって始めたら良いのかわからない、実際にどんな感じになるのか想像ができないのでほんとに意味があるのかわからない、なんか面倒くさそう、など、TDDへの興味はあるけれどなかなか最初の一歩が踏み出せない、という方にぜひ見ていただきたいです。(2018年のPHPカンファレンスでのセッションをブラッシュアップし、2020年代のTDD初心者の皆さまに向けて改めてお送りします)
現在多くのWebサービスではメールアドレスをIDとしてユーザー情報を管理しています。
このようなユーザーを管理するDB設計はWeb開発の基礎とも呼べるもので、多くのWebフレームワークも基本機能として備えています。
このようなサービス運用のためにいくつかの考慮事項があります。
要約するとたった二点ですが、実際の要件はサービスの運用形態や提供したいユーザー体験に併せて様々に異なってきます。
たとえば、同じユーザーからの複数回の登録を許容しない、特定のドメインからの登録を禁止するなどです。
明確な要件に見えても、現実にはそう単純に実装できない要素がいくつもあります。
メールアドレスや関連仕様、DB製品とCollation、メール配信サービスプロバイダ、ユーザー認証プロバイダなども影響します。
今回のトークではメールバリデーションライブラリの実装を通じて、アカウント管理に必要な観点についてみつめなおしましょう。
昨今ソフトウェア開発においてモデリングの重要性が解かれています。
ですがそれらは業務知識に結びついた話になりやすいです。
対象への理解がないと自分ごととして捉えづらい(ピンと来ない)でしょう。
そこで理解しやすい図形「三角形」を題材にし、共通認識をもったうえでモデリングの練習をしてみましょう。
サイボウズのGaroon(ガルーン)は今年で20周年を迎えるグループウェアです。
このセッションでは、20年にわたって開発が続いている巨大なレガシープロダクトのPHPバージョンを7.4から8.0にアップデートした際に得られた知見についてお話しします。
Garoonはさまざまな組織を支えるグループウェアであり、お客様の業務にまつわるデータをお預かりする性質上、セキュリティの確保が重要な課題です。
そのため毎年欠かさずにPHPのメジャー/マイナーアップデートを行い、常に最新のセキュリティ更新を取り込める状態を保っています。
しかしGaroonはPHP4系の時代から脈々と開発が続いているため、コードベースは巨大でありレガシーなコードが多分に含まれています。
さらにPHP本体にパッチを当てて自前でビルドしていることもあり、PHPのバージョンに対する依存度も高いです。
今年はPHP7.4からPHP8.0という影響の大きいアップデートを計画したため、約一年かけて準備を行なってきました。
その中で、比較演算子の問題をはじめとする、特に対処が困難であった以下のトピックについて詳しくお話しします。
結果的に、紆余曲折ありつつもPHP8.0へのアップデートが完了できました。
GaroonのPHPをアップデートするために具体的にどのように準備をおこなったのか、またその中で得られた知見を共有することで、
これからPHP8系へのアップデートを行う方々の助けになれたら幸いです。
API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュート(アノテーション)を1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう優れもので、Symfonyのエコシステムにおいてはすでに決定版と言える存在となっています。
しかしながら、ある程度以上複雑なことをしようとすると途端にフレームワークについての深い理解が求められたり、痒いところに手が届かず強引なワークアラウンドが必要になったりするという面もあり、入門と実戦の間には大きな隔たりがあるように思います。
このトークでは、まずはAPI Platformの導入方法から、Data Provider・カスタムコントローラ・Data Persisterといった重要な基本機能の概要までを、実際に動作するデモをお見せしながら丁寧にご紹介し、さらに、よくあるユースケースで必要になるワークアラウンドなど、実戦投入に向けた実装のテクニックをお伝えします。
API Platformの実戦投入、あるいはその検討の一助になれば幸いです!
PHP では言語に対する変更に対し必ず RFC (Request for Comments) 文章を作成し、投票で一定数以上の票を獲得する必要があります。
またその提案に対する議論は必ず Internals ML と呼ばれるメーリングリストにて英語で行う必要があります。
上記のようなハードルの高さからか、比較的 PHP の利用率が高い日本からの新機能の提案、実装の例は少ない印象ですが、実際にやってみるとどうなのでしょうか。
今回は RFC を作成、実装し、 PHP 8.2 で実装が決まった Random Extension 5.x を例に PHP への新機能追加・変更を行っていくまでの道のりについてお話できればと思います。
PHPカンファレンスの初期の頃から続けている初心者向けのセッションです。
PHPとはどんな言語か
PHPの実行環境にはどんなものがあるか
スクラッチでのPHPの書き方の基本
このセッションをお聞きいただけると手元で簡単なPHPのコードを実行することが出来るようになります。
・対象となる方
このセッションではPHPを普段使われていない方、プログラミングを始めて間もない方を対象としています。
・対象とならない方
ご自分でマニュアルを見て環境設定、プログラミングが出来る方は対象外です。
様々なロジックが密に結合したモノリシックなアプリケーションは開発速度を遅くする一方で、マイクロサービスアーキテクチャはサービス間のコミュニケーションやトランザクションなどといった別の課題があります。
モジュラーモノリスは、モノリシックなアプリケーションの中にドメイン境界を引いて疎結合な状態をつくる、モノリスとマイクロサービスの中間的なアーキテクチャです。
このトークでは、モジュラーモノリスをLaravelアプリケーションに適用する方法を具体例を用いながら紹介します。Laravelを例にしていますが、他のフレームワークにも適用できる内容です。
Laracon Onlineで話した内容に少し付け加えて日本語で話します。
https://www.youtube.com/watch?v=0Rq-yHAwYjQ&t=4057s
フラットなPHPの書き方はわかった、では次はフレームワークへ…というとき、どんな基準でフレームワークを選んでいますか?なぜそのフレームワークを使ってアプリケーションを書くと良いのか、理解できていますか?堅牢でメンテナブルなアプリケーションを作るとき、なぜフラットなPHPでは難しいのでしょうか?
入門書や動画講座でPHPの基本文法を学んだあと、盲目的に次のステップとしてフレームワークを学習するのではなく、必要性を実感した上でフレームワークを学習してほしい、と私は常々考えています。
このトークではフラットなペラ1枚のPHPスクリプトから出発して、オブジェクト指向で自動テストのできるPHPアプリケーションへ、そして更にフレームワークを使ったアプリケーションになるまで、コードと考え方をお話しします。
◆含まれるもの
◆含まないもの
■ 発表内容
チーム開発に効果的なアジャイルのプラクティスとその実践例を紹介します。
■ ストーリー
「ゴールデンウィーク明けまでにこの機能を作ってほしい」と社内向けの新規機能の開発を任されたとあるチーム。このチームは4月頭に組成されたばかりであり、開発する機能はビジネスの成長ドライバーになることを期待されている。期間は1ヶ月しかない。ただし、その1ヶ月に根拠はない。
チームの構成はプロダクトオーナー1名、エンジニアマネージャー1名、エンジニア6名。不確実性に対処しつつ円滑にリリースを行うべく、アジャイルのプラクティスを実践して開発に立ち向かっている(6月上旬にリリース予定日が立てられて、6月下旬にその日通りにリリースできた)。確かに当初の予定よりは遅れている。
しかし、チームのエンジニアの誰一人として疲弊しきっていない。むしろ、組織の中で偉いAさんは「遅れていても、着実に進んでいることがわかる上に、遅れの理由が納得できるので安心感がある」と言い、スクラムマスターBさんは「このチームではスクラムがうまく回っている。もしそうでなければ、リリースはさらに1ヶ月以上遅れていただろう」と述べている。
なぜそれが可能なのか。何がうまくいっているのか。チームで実践したアジャイルのプラクティスとその実践例を紹介します。
■ 発表内で登場するキーワード(予定)
アプリケーション開発をしていると、どうしても不具合は生まれます。
バグ、障害、故障、エラー…近接する概念が色々とありますが、その中でも「プログラムetcの修正で修復できるもの・根治できるもの」が確かに存在します。
実際の所、皆さんのサービスで、それらはどのくらい発生しているでしょうか?その内、直せるはずの「バグ」「欠陥」はどのくらいあるでしょうか?
パッと答えが浮かばない、という方も多いと思います。
どうやってこの状況を脱していきますか。
とにもかくにも、「可視化」「現実的な目標」「コントロール可能な状況を作る」「割れ窓状態を脱する」のが重要だと思います。
そして、それに勝るとも劣らず「なぜ、エラーを少ない状態を実現したいのか。そこにどんな価値があるのか」という認識の統一も欠かせません。
チーム全体を方向づけ、小さな実践を押し進めながら「それらは夢物語なんかじゃない」と勇気づけるような成果を上げていきましょう。
本セッションでは、まずは「エラーやバグがもたらす不経済」について説明します。併せて「なぜ、検知と修復を急ぎたいのか」「遅れが何をもたらすか」も扱います。
その後に、自身の体験も踏まえながら「どうやって・何を努力していき、チーム一丸となって”エラーを減らす”を実現していくか」について共有します。