トーク

EOL対応はエンジニアの永遠の課題ですよね。
弊社では5つのサービスがPHPで作られており、そのうち4サービスは10年以上の歴史を持つサービスです。
そんな中始まったPHP8へのバージョンアップ対応は一筋縄ではいきませんでしたが、以下のステップで取り組んだことで大きな問題なくバージョンアップを終わらせることができました。

1. 5つのサービスの担当者間で注意すべきポイントなどを共有
2. 担当サービスの技術特性や抱えている事情の違いを考慮してアプローチ

このセッションでは、弊社の全5サービスで行ったPHP8へのバージョンアップ対応の取り組みやそこから得られたノウハウをご紹介し、これからPHP8へのバージョンアップを検討されている方に有益な情報をお届けできればと思います。

Laravel Octane（オクタン）は、SwooleやRoadRunnerなどの高性能なアプリケーションサーバを使用し、アプリケーションを提供することで、アプリケーションのパフォーマンスを向上させます。Octaneはアプリケーションを一度起動したら、メモリ内に保持し、そして超音速でリクエストを送り返します
（引用：https://readouble.com/laravel/8.x/ja/octane.html）
Laravel Octane（Swoole版)でPharをつかってワンバイナリアプリケーションにして運用してみた話です
過去、PHPカンファレンス北海道（２０１９）にて
「pharによるワンバイナリアプリケーションの可能性を探ってみた」
でお話ししましたが、そのリベンジ（現実版）になります
PHPだけど、Buildして(Pharでpackして）、Deployして運用してみよう！

みなさん、あなたが保守しているコードベースで一番バグが混入しやすいファイルが何か知っていますか？

このトークでは、保守容易性指数（Maintainability Index)とGitHubのコミット数を用いて、
保守性が低くて、よく変更されているファイル(= バグが混入しやすいファイル)を見つけ出す方法についてご紹介します。

みなさん Composer 使ってますか？使ってますよね〜〜〜？？
Composer のようなパッケージマネージャのおかげで、パッケージの依存関係を明らかにしたりパッケージの依存関係や実行環境の依存関係にあわせてパッケージを適切なバージョンにアップデートすることもできます。

一方で、定期的にパッケージのバージョンアップを行うのは手間ではあります。その一手間を減らしてくれる dependabot や WhiteSource Renovate といった自動でパッケージのアップデートを Pull Request にしてくれるツールが登場します。

本トークでは、 Composer を利用しているプロジェクトにおいて、 WhiteSource Renovate を用いたアップデートに関する Pull Request の自動作成戦略についてお話しできればと思います。

自動テストにおけるテストフィクスチャは、ほぼ全てのソフトウェアにおいて必要になるテクニックです。その中でもデータベースと密接に連携する Web アプリケーションにおいては、データベースにデータを投入し、そのデータをフィクスチャとして利用するテクニックは初期の頃から利用されてきました。

PHPにおいては、 Fabricate という Ruby における factory_bot のような"柔軟な定義構文を用いてフィクスチャを管理する"ためのパッケージや、ここ最近になって CakePHP Fixture Factories という Fabricate に近しいコンセプトのパッケージが登場してきています。

本トークでは、最近登場した CakePHP Fixture Factories の解説を中心に、新たなテストフィクスチャ管理ツールのスタンダードについてお話できればと思います。

世は大 Laravel 時代を迎えています。業務でも Laravel を採用している会社はそれなりにいるのではないでしょうか。
しかし、「依存を増やす」ということは「障害点を増やす」ことと同義です。
「Laravel は安定しているからロックインされてもいい」とみなすことも出来ますが、業務では「最悪の場合」も想定して選択していく必要があります。
DDD の文脈では（私は DDD 初心者ですが）、ビジネスロジック(ドメインロジック)を重要視します。フレームワークはビジネスロジックをサポートしますが、直接依存しない方が安全です。
このトークでは、「いつでも Laravel を捨てることもできる疎結合な設計」を紹介します。

対象者

• OSS フレームワーク・ライブラリを利用する全ての皆様
• アプリケーションを疎結合にしたい方

成長するためにアウトプットというのは非常に重要ですが僕のまわりでは
・プライベートで開発ほとんどしてないからネタがない
・公開できるようなネタがない
・とにかくネタがない
ということが非常に多いです。

僕も最近はプライベートで開発できてないので、めちゃくちゃ気持ち分かります。
でも我々は日々業務で技術に触れていますし、日々学んでいますよね？
だったらそれをアウトプットすればいいのです！

もちろん業務で得た知識をそのまま一般公開することはできませんし危険です。
外部に出してはいけない情報もあるでしょうし、場合によっては情報漏えいにも繋がります。
そういう知識をアウトプットするには「抽象化する」ことがとても重要です。

本セッションでは「知識の抽象化」の仕方を実際に僕が経験したことを例に説明します。
このセッションで少しでもアウトプットへのハードルが下がると嬉しいです！

昨今のプロダクトの改善・開発を実施していくためには、データを可視化・分析することはこの時代必須といえます。
特に、アプリケーションエンジニアにも一定のリテラシーが求められている時代だと考えられます。
しかし、そのために必要なデータはRDB、ログなどの様々な形式、場所にあり横断的な分析をすることは容易ではありません。

そこで、私たちのアプリケーションの分析環境をBigQueryに構築したエピソードをもとに、以下の知見についてトークします。

• embulkを使ったBigQueryへの転送パターン
• 便利な集計クエリのパターン
• BigQueryの権限管理ついて
• BIツールのLookerを用いたデータ監視について

NoSQLのような可用性・柔軟性を持ちながらSQL・トランザクションをサポートすると言われているNewSQL（Cloud Spanner, CockroachDBなど）の導入事例が最近目につくようになってきました。
ですが、NewSQLと既存のNoSQLとの違い、また実際どのようなメリットがあるのか、よくわからない部分も多いと思います。
今回の発表ではNewSQLの1つであり、MySQL互換のTiDB(タイデービー)をローカル環境でセットアップして、PHPのアプリケーションからつないで使ってみるところまでを、発表したいと思います。

アプリケーションエンジニアの視点から調査した以下の内容をまとめて発表予定です

• NoSQL, RDBとの違いとNewSQLのメリット
• TiDBをPHPから動かしてみる

PHPは主にHTTPサーバアプリケーションの実装に用いられますが、案外長い時間がかかるバッチ処理なんかも書けたりします
数十分～数日かかる処理まで、長い時間がかかる処理をPHPで並列で回す方法や気を付けるべき点などを、仕事で主にインフラを担当している自分が実際に業務であった経験ををもとにお話します

突然、元気に呼びかけて申し訳ありません！
言いたいことは掲題のとおりでございます。

Web業界やソフトウェア産業、とっても忙しいと思うんですよね。
やる事が多い！巷では、やれアジャイルだ、リーンだ、DXだ・・・と騒がれて久しい。
なんでも、「コードを書いてりゃOK」ではないような雰囲気がムンムンしちゃって。
「視座の高さ」「視野の広さ」がより求められている感じがします。

そんな幅広い職業に居る我々の「生産性」ってなんでしょうね？
(私、ここ1年ほど、職場でそんなことばっか考えてる。)
そのヒント、書籍「LeanとDevOpsの科学」にあります。
価値を届ける、確実性を上げる、無駄を削ぎ落とす・・「それって何？」に真っ向から向き合った1冊です。
ソフトウェア開発の「生産性」について考える、「改善」について考える、そんな取っ掛かりになるように書籍の紹介をします。

コードレビューは難しいですね！
異なる考え方・レベルにある他者同士、ぶつかってばかりではいられないけど「何も言えない」のでは意味がない─
そんな複雑で繊細な仕事に、どう向き合えばよいでしょうか？

本セッションでは「レビューは何が難しくて、"怖い"のか」について考えます。
その上で、コミュニケーションやチーム作りの分野にヒントを求めて「明日からできそうなこと」を紹介します。

以下のような書籍をヒントの元として想定しています(一例)。

• アジャイルプラクティス
• 学習する組織
• NVC 人と人との関係にいのちを吹き込む法
• あなたのチームは、機能してますか？

お届けしたい事

• 「威圧したい訳ではない！でも妥協もしたくもない！！」を両取りするためのヒント

扱わない事

• プログラミングの知識、技術
• コードのクオリティを高めるためのノウハウ

Composerには、Pluginという仕組みがあります。
2.0が来るまでは、hirak/prestissimoにお世話になっていた方も多いと思います。(私もその1人です！！)

では、「どういうことが出来るのか」はご存知ですか？
知ることが全ての始まりです。
もしかしたら、あなたの仕事に革命を起こすような素晴らしい可能性が眠っているかもしれません。

「Composer Pluginとはなんだろう？」とイメージを掴むために、「どういう仕組みになっているのか」「どういう機能があるのか」を紹介したいと思います。

お届けすること

• Pluginの仕組みと概念を知り、開発者体験の向上を進めるための引き出しを増やす
• 実例を通じたPluginの効果・ユースケース

話さないこと

• Composerの基本的な使い方、仕組み
• Composer v1.xからv2.xへの移行

先行きの不透明な開発プロジェクト。
鳴り止まない障害アラート。
挙句の果てに、リリースした機能がユーザーにあまり使われていない！
そんな課題を解決すべく、ごく普通の PHPer がある日突然スクラムマスターに任命されて...！？

エンジニアがスクラムマスターに任命される。
まれによくあるイベントです。

このセッションでは、

• スクラムとは何か
• 冒頭で挙げた課題に対して、スクラムではどのように立ち向かうのか
• エンジニアとしてどのような能力をスクラムマスターに活かせるか
• 逆に注意すべきポイントは何か

といった内容を、 PHPer からスクラムマスターに転身した自分の体験を踏まえて紹介します。

中小ベンダーのエンジニアとして、有象無象のWebシステムの開発や保守に関わる中で、本当にあった、身の毛がよだつようなアプリケーション脆弱性のお話や、笑えないセキュリティインシデントのお話を、怪談風に（・・・の予定で）お話しします。

第一話は、他社から保守を（引き継ぎなしで）引き継いだ、証券会社の顧客向けマイページシステムが、恐ろしい脆弱性だらけだったお話です。

調査結果の一次報告のとき、「このことは口外禁止でお願いします。明るみに出ると死人が出ます」と言われたことが今でも忘れられません。

第二話は、WordPressサイトが攻撃されて相談を受けた数々の事例の中で、一番悲惨だったお話。

時間が許せば、自社のやらかし（未遂）事例などもお話ししようと思います。

WordPress でサイト作って約7年、「WordPress 完全に理解した」の先に待っていた失敗事例を踏まえつつ WordPress が人類に提供しているあれこれを俯瞰します。
最後に、近年の CMS に求められている機能とからめて WordPress が愛される理由について持論を展開してみます。

昨今、RDBMSを用いてサービスを作ることは非常に多くあると思います。

堅牢なテーブル設計を行っておく事は非常に重要で、バグが生まれづらくなったり仕様変更にも強いなど得られる恩恵は多いです。
逆に複数の関心事が集まったテーブル設計を行ってしまった結果、データを取得する為のSQLがややこしくなったり、仕様変更に弱くなる事も多くあります。アプリケーションと比べてデータベースは寿命が長く、その頃にはリファクタリングすら着手する事が難しいという事も多いですよね。

本セッションでは、データモデリングを学んでいなくても致命的な問題が起こりづらいテーブル設計手法について大規模WebサービスのDBリファクタリングをやった経験を踏まえて紹介させて頂きたいと思います。

ソリューションドメインという単語をご存知でしょうか？
ソリューションドメインとはPHPのようなプログラミング言語やMySQLのようなデータベースといった技術に関するドメインですが、ソリューションドメインに関する知識が少ないと、不必要な複雑さをアプリケーションに持ち込んでしまったり、適切でないモデルを構築するハメになってしまうことがあります。

エンジニアであれば技術の勉強を通してソリューションドメインへの理解を深めているはずですが、このトークでは改めてソリューションドメインについてまとめたいと思います。

• ソリューションドメインとは何なのか
• 設計とソリューションドメインの関係性
• ソリューションドメインを学ぶことで設計にどのような影響があるのか
• どのような問題ドメインに対してはPHPを使わない方がいいのか

Webアプリケーションを長年運用していると、至る所でパフォーマンスの問題が出てきますよね
リリース当初は問題なく動いていたものが、突然動かなくなるなどの経験をした方も少なくないのではないでしょうか

私たちの運用しているLaravelアプリケーションも例外ではなく、稀にデータベースが悲鳴をあげたり、特定条件でアプリのレスポンスが遅くなったりという状況に遭遇する機会が増えてきました

そんな問題の特定・解消のために導入したのがDatadog APMでした
発行されているSQLの数や処理時間、外部APIのコールやphpの処理時間などのデータが全て見える化されており、非常にパフォーマンス改善しやすい環境を作ることができました

本セッションではそんなDatadogの導入までにやったことやDatadogを活用してどうやって改善を繰り返しているかなど、事例を交えてご紹介したいと思います

なんか純粋にSymfonyの好きなところをお話ししたいなーって思いました。

PHPのフレームワークはたくさんありますが、その中でもぼくはSymfonyが好きです。
Symfonyの好きなところを20分かけてお話しします。
みなさんにSymfonyって面白そうだなー、さわってみようかなーって思ってもらえるようがんばります。