我々アプリケーションエンジニアにとってデータは非常に重要なものです。
皆さんもRDBのデータ、ログデータ、分析データといった色々な種類ものを扱うことが多いのではないでしょうか？

しかし、これらのデータはエンジニアだけのものではなく、マーケター、事業責任者といったプロダクトに関わる全員が関わるべきものではないでしょうか？
そのためには、SQLの習得といったスキルの問題や、業務サービスへのアクセス権限といったガバナンスの問題もあり、なかなか難しい課題なのではないでしょうか？

そこで、我々の開発チームでは、開発だけでなくプロダクト全てのサイクルに関わる"Fullcycle Developers"という標語を抱えています。
その一環で、我々が作ったプロダクトの成果をデータ含めてフィードバックループを作るようにしています。

その結果、BIツールを用いて、SQLを出来る限り書かずともチームの皆がデータを可視化・確認できるようになり、開発に関する議論も職種問わず活発化しました。

そこで今回のトークでは、我々のチームが、どのようにデータの民主化を進めていったのか、データの民主化によってどのような変化があったかをお伝えします。

具体的なBIツールなどの使い方などに関しては話さない予定です。

発表者の会社では、複数のWebサービスをオンプレミスの複数のKubernetesクラスタ上で運用しています。
手元からのkubectlなどKubernetesクラスタへのアクセス権が必要となります。そのため、生産性を損なわずに安全性を担保してアクセス権を得られる仕組みを用意しています。

本セッションでは、以下のお話をします。

• オンプレミスKubernetesクラスタへのアクセス権付与に伴う課題
• HashiCorp Vaultを認証局としたmTLS（相互TLS）とGithub Personal Accessによる2要素認証・認可によりアクセス元ユーザのみに最小限のアクセス権を付与する仕組み
• Vaultからクライアント証明書を発行しkubeconfig（Kubernetesクラスタにアクセスするために必要な情報を格納するファイル）を自動生成する仕組み

みなさんのアプリケーションではUIがいつの間にか壊れている、ということはありませんか？
とあるUIコンポーネントが予想しなかった箇所で段落ちして崩れていたり、はみ出ていたり。CSS完全に理解したTシャツよろしくなことになったことはありませんか？

このトークではマイクロソフトのOSSであるPlaywrightの試験的な機能であるコンポーネントテストのスクリーンショットテストを用いた、リグレッションテストについての使い方・運用方法などを紹介します。

スクリーンショットによるリグレッションテストを行うことで、UIが期待した状態で描画されているかを視覚的に確認することができます。
またプルリクエスト時にもスクリーンショットによる視覚的なレビューを行うことが容易になるためスムーズなコミュニケーションにも期待できます。
本トークはPlaywrightによるリグレッションテストを実際のプロダクションで使っている事例を紹介します。

※このトークではPHPの話はありません。

少数を整数にしたり、大きな数字を有効数字にしたりするために四捨五入（丸め)をすると思いますが、その時にPHPでは「round()」関数を用いると思います。
round関数には第三引数にオプション値がありますが、引数を省略した場合、文字通りの四捨五入(有効桁より一つ下の桁が5以上なら有効桁が1大きくなる : PHP_ROUND_HALF_UP)となります。

実はその丸め処理、安直に四捨五入を選ぶと計算や動作に問題が出ることがあります。
先日ちょっとした問題になり、良い機会なので発表したいと思います。
当方ン十年エンジニアをしていましたがずっと意識したことがなく、多分皆様もそうじゃないかと思いますので。

※今回の話はPHPに限らずどの言語でも当てはまると思います

GitOpsによるAptリポジトリの自動管理

発表者のチームでは、数百台のサーバに対して独自ビルドしたプライベートなDEBパッケージを配信する必要があります。

私が所属するチームでは、GitのPull Requestベースの開発フローに則るだけでAptリポジトリへの自動リリースをする仕組みを開発しました。パッケージングやAptリポジトリの生成といった複雑なオペレーションを開発者が意識しなくて良くなっています。
また、Aptリポジトリをイミュータブルなアーキテクチャで構成しているため、障害発生時に簡単に復元できるようになっています。

本セッションでは、以下のお話をします。

• Github Actions とパブリッククラウドを組み合わせてAptリポジトリを冪等かつ自動的に生成する実例
• 独自DEBパッケージや既存DEBパッケージへのパッチ管理等のソースコードの管理方法

応募者の業務中に最近起きた話を共有します。フリーランスである応募者は PHP-5.5、FuelPHP-1.8、AWS RDS MySQL 5.6 というレガシー環境で社内システム向け Web アプリを開発していました。
AWS は2022年2月に RDS での MySQL 5.6 のサポートを終了し、2022年3月以降に MySQL 5.7 への自動アップグレードを開始しました。いざ MySQL 5.7 にアップデートを行うと、アプリケーションの特性が要因となって、ORマッパーが生成する SQL に対して、いくつかの問題が発生しました。JOIN を多用する SQL に対して、内部的に生成するテンポラリテーブルの、カラム数やバイト数が限界に達したのです。この問題に対してシンプルな回避策は見つからず、DB 管理者は MySQL 8 へのアップグレードすることでの解決を模索します。実際に MySQL 8 との組み合わせを検証すると、今度は PHP の古さが原因となった問題点が発生しました。MySQL 8 から標準文字セットとなった utf8mb4 を PHP-5.5 の mysqlnd は理解できず、接続時にエラーとなってしまうのです。utf8mb4 がサポートされた mysqlnd は PHP-7.0.19 からです。PHP-7 に一気に上げると、おそらく他の部分にも様々な修正が必要となってくるでしょう。この八方塞がりな状況をいかに解決したかというお話をさせていただきます。

オチを少しだけバラすと、このシステムは PHP-5.6 と MySQL 8 の組み合わせで現在動作しています。

万人を虜にし、数多くのエンジニアを型に嵌めたフレームワークという存在。某WordPressをはじめ、全世界のアプリケーションインフラを支える大黒柱ではあるが、彼らも時代とともに変わっていく。

自分自身も毎年脱皮を繰り返す彼らを業務上で付き合っていく中で、四苦八苦することがあるが、果たしてどのように関係を保てばいいものだろうか。

コントリビューターたちの軌跡を常にキャッチアップするほど、我々に時間は与えられていないし、業務は待ってくれない。

業務を通して、かつ、フレームワークの複雑さや進化と付き合ってきた、僕なりの方法をお話します。

・Laravelを使った開発における注意点
・PHPUnitを用いた設計・実装における勘所

"品質"

IT業界では長らく「ふわっと」利用されてきた言葉です。

ですが、"品質"には定義があります。
あなたは"品質"について説明できていますか。

このトークでは"品質"の定義とシステム開発において要求される"品質"の満たし方についてお話します。

このトークで得られる知見

• "品質"の定義
• "高品質"の達成の仕方
• ユニットテストにおける"「どこまでやるか？」の割り出し方"

このトークで話さない事

• 品質工学

人はいつか、数十万～数百万行もの巨大なコードベースに立ち向かわなければならない時が来るものです。
このような、一人の人間が把握できる許容量を超えたコードベースを調査する羽目になったとき、どのような手法を取ればよいのかを説明します。

主な対象

• 巨大なソフトウェアのソースコードを読んだことがない方
• 巨大なソフトウェアに到達した時点で調査を打ち切っている方

話すこと

• ソースコードに突撃する前にできること
• ソースコードを効率的に読む
  • 構成を把握する
  • 該当箇所を見つける
  • 読む量を減らすには

話さないこと

• 特定の言語でしか使えない how-to (デバッガの使い方など)

目標

• 巨大なソースコードに立ち入れるようになる
  • あわよくば、実務で問題を解決する
• (php-src を読む人を増やす)

アプリケーションを開発するなかで設計手法が必要と感じたら、DDD（ドメイン駆動設計）が選択肢の一つです。

最初からアーキテクチャを導入するわけではなく、約10年成長してきたLaravel的なEloquentを活用したMVCで作られたアプリケーションにアーキテクチャを導入する際、悩みや数々の試行錯誤がありました。

私たちの経験を元に、オニオンアーキテクチャをベースに、既存コードの対処法やネームスペース、クラス分割のコード例と背景を紹介します。

想定対象

• 既存プロダクトにDDDを導入したい方
• Laravelにオニオン（レイヤード、クリーン）アーキテクチャを取り入れて見たい方

話すこと

• 既存コード（主にEloquentとUtilクラス）との付き合い方
• ネームスペースの切り方と背景
• クラスの分割と背景
• DIの方針と背景

話さない内容

• DDDを使う理由
• モデリングに関すること
• ドメインロジックの定義

ウェブサイトのコンテンツ管理とテンプレーティングはWWW初期から長らく課題とされてきました。

コンテンツ管理システム(CMS)というアイデアの原型が生まれたのは25年ほど前ですが、現在でも世界のウェブサイトの多くはWordPressに代表されるCMSで運営されています。
一方で、コンテンツ管理とテンプレーティングという課題に対する別のアプローチとして、静的サイトジェネレータ(SSG)という概念も発生し、今日でも発展を続けています。

CMSとSSGは二者択一のものとして解釈されがちですが、近年ではHeadless CMSのような折衷案も登場しており、周辺のスタックまで含めると選択肢は無数に存在すると言えるでしょう。
これらの選択肢を個別に検討するときりがありませんが、検討のための手がかりはないのでしょうか。

スピーカーはその手がかりが「歴史」にあると考えています。
ある技術やソフトウェアが開発されるには、それまでの出来事からニーズが発生するためであり、そのニーズを読み解くことで強みを見抜くことができるでしょう。

LAMPからJAMStack含め最新の動向まで、WWWの歴史やエンジニアリングの歴史とともに俯瞰していきましょう。

先日、4月19日に福岡発のオープンソース、baserCMSの最新バージョンがリリースされました。
世の中において、PHPにおけるフレームワークのニーズは、Laravelがうなぎ登りですが、baserCMSは、オープンソースとして外部のコードが受け入れやすいよう、規約重視であるCakePHPを採用し、最新バージョンもCakePHPで開発されています。

最新バージョンであるbaserCMS５の開発では、レガシーコードからの脱却を目指し、これまでの12年間の開発で熟成した「秘伝のタレ」的なコードを全て見直し、モダンな開発プラットフォームとして成長しています。

実は2017年より、ゆっくりとその開発が始まりましたが、その過程の中で、目指すCakePHPのバージョン対象が３から４へと変化し、そして、先日のbaserCMS５のリリース前に、ついにCakePHP５のベータ版が勧告されてしまいました。

このセッションでは、開発中のエピソードや移行のポイント、また、DIやサービスなどの概念を踏まえ、土台となるフレームワークがどのように変化しようと心が折れないアーキテクチャーとは何かについてお話できればと思います。

普段業務システムの開発などが多く、あまりユーザー数が多いアプリケーションの実装をしたことがないWebエンジニアの方向けに、はじめての大規模ユーザー数（ユーザー数10万人以上）のアプリケーション実装において失敗しがちなポイントとその回避法を解説します。

失敗しがちなポイント例

・CSVやExcelでの入出力系の実装
・通知機能の実装
・インフラ構成の設計
・負荷試験の実施方法
・データベースのトランザクションの設計

上記の様な気をつけるべきポイントを抑え、大規模なユーザー数に耐えるシステム実装の基礎を学びましょう。

また、大規模ユーザー数のアプリケーションにおいて、追加開発の要望が多く発生する場合に、どのようにスピーディにチームで開発を進めていったか、についてもお話できればと思います。
本セッションを通じて、初心者でも安心して大規模なユーザー数に対応したシステムを実装するためのポイントを学んでいただけます。

ChatGPTを使って、AWS上で簡単にサーバーレスアプリケーションを開発する方法を紹介します。
このセッションでは、結婚式やパーティーなどの余興に活用できる写真投稿アプリケーションを例に、ChatGPTとServerless Frameworkを使った構築手順を解説します。AWSに自信がない人でも、簡単にサーバーレスアプリケーションを開発できる、そんなChatGPTの活用方法をお話します。

内容
・サーバーレスアプリケーションとは？
・写真投稿アプリケーションの設計
・ChatGPTを使ってServerless Frameworkを用いてAWS Lambda、S3、API Gateway、DynamoDBなどをAWS上にデプロイする手順

対象者
・AWS初心者、特にサーバーレスアプリケーションに興味がある人
・ChatGPTを使ってAWS上でアプリケーションを開発したい人
・結婚式やパーティーなどの余興に活用できるアプリケーションを開発したい人

PHPエンジニアを吸い込んでいると言われるLinkage。
そのLinkageで行っている 採用のコツ について解説します。
こんなお悩みがある人達に明日から使えるノウハウを伝授します。

• カンファレンスにスポンサーしているけど注目されない
• ノベルティが話題にならない
• エンジニアを採用したいけど応募がこない

※個人の主観が多く入るため、再現性については個人差が出ます

PHP は、気軽にウェブアプリケーションを作れる言語として、初心者から熟達者まで、人気のプログラミング言語です。
しかし、せっかく作ったウェブアプリケーションも、保守・運用で扱いにくいとレガシーアプリケーションとか、技術負債などと呼ばれます。また、PHP を忌避するエンジニア達も存在していて、レガシー化しやすいから PHP で新しいアプリケーションは作りたくないと評されたりもします。

しかし、保守性の高いウェブアプリケーションとなると、難しい設計論とかアーキテクチャーとかの話が出てきて、どうやっていいかよくわからなくなります。
なんとか、PHP の気軽さを保ちつつ、保守・運用がしやすいウェブアプリケーションを作ることはできないだろうか？
本トークでは、なるべく難しい設計論を避けつつ、どうやったら無難で、レガシーになりにくく、レガシーになったとしても何とかなるウェブアプリケーションが作れるかをまとめます。

本トークでお話すること

• レガシー化しにくくなる PHP ウェブアプリケーションの基本方針
• 明快で分かりやすい開発時の約束事
• 負債を生み出しにくい開発フロー・開発組織の仕組み作り

ソフトウェア開発において、データとして数値化できるものを管理可能な状態にまとめたものをメトリクスと呼びます。"Lean と DevOpsの科学" で有名になった Four Keys なども４つのメトリクスをまとめたものです。

ソフトウェアの改善においては、まずメトリクスを計測し、KPI を定め、改善を進めるのが王道です。

うちのアプリケーションは複雑で理解しにくい。そんな話は、ある程度成功したウェブサービスであれば、どのサービス事業会社でも聞けそうな発言です。では、その複雑とは、一体どんな原因によってもたらされているのでしょうか？その複雑さは監視・改善できるのでしょうか？

本トークでは、複雑性の監視に使えるツール類と、計測できるメトリクスを紹介し、どうやってそれを継続監視して改善に活用するかを紹介します。

本トークで話す内容

• 複雑性とはなにか
• メトリクスの測り方、継続監視の仕方
• 複雑性改善の方法

B+木をご存知でしょうか？RDBMSのインデックス作成に採用されているデータ構造で、ディスクの効率的な利用や、検索を行いやすいなどの特徴があります。しかし、耳学問で聞いてもイマイチ特徴がピンと来ないのです。

本トークでは、PHPでB+木のデータ構造を実装して、RDBMSでB+木が採用される理由、インデックスの構造的な仕組み、何故検索が速くなるのか？などなど、データベースの仕組みの根幹を覗いてみましょう。

本トークで話す内容

• B+木の特徴
• なぜ、データベースはB+木を採用しているのか
• インデックスとは何か

2023年11月23日に PHP 8.3 がリリースされます。本トークでは、追加が確定している新機能を紹介すると共に、その機能がどんな議論を経て追加されたのか、この先の展望も含めてわかりやすく解説します。

また、要望はされたものの却下された機能の話や、現在議論中の機能についても紹介します。

本トークで話す内容

• 現時点で追加が確定している機能
• これから追加される見込みの機能
• 要望はあるものの追加されなかった機能

2018年にPHP勉強会@東京にて「Laravel Collection の計算量を調べてみた」を発表しました。
https://speakerdeck.com/hanhan1978/laravel-collectionfalseji-suan-liang-wodiao-betemita

あれから、5年。月日が流れて、Laravel 10 がリリースされ、Collection にはメソッドが追加され、ロジックにも変更が入りました。
今、計算量がどうなっているのか測り直します。

Collection で要注意な関数はどれなのか？どんな処理を行うとパフォーマンスが劣化しやすいのか、再調査しました。
Laravel 使いの皆様必見です。