皆さんはCTO、VPoE、部長、本部長などの役職に就いていたり、キャリアの中でそういったロールに就任することを目標としていますか？
一般的には、役職への就任はポジティブなものとして受け取られることが多いのではないでしょうか。

しかし、私を含めた私の周囲にいる前述のような役職に就いたエンジニアに話を聞くと、どうも本人が望んでいないのにそうなってしまったケースが多いです。
そういった事例を見聞きする中で、本人が望む望まないに関わらず役職に就いてしまうエンジニアの共通点を理解してきました。

PHPカンファレンスに出席するような勉強熱心な方は、出世などせずにIndividual Contributorとしてキャリアを続けたいと考える方も多いのではないでしょうか。
実は、そういった指向の方こそが役職に就いてしまう傾向があると私は考えています。

本トークでは、私がキャリアの中で出会ってきた「気づいたら役職に就いていた」ソフトウェアエンジニアのケースを元に、そういったキャリアを望んでる方には今後目指すためのヒントを、役職に就いてしまった方には出口戦略について考える機会を作れたらと思います。

免責

• 本トークの内容はPHPに関連しません

概要

エンジニアは継続して勉強する必要があると言われています[要出典]。ただじゃあなにをどうやって学ぶのかはあまり教えてくれません。コードを書いて公開すればいいよとか、本を読むといいよとアドバイスはしてくれるものの、具体的な行動に移すのが難しいなあと感じます。

そんなふうに思っていた自分は今では、年間で、本をたくさん読み、ポッドキャストをたくさん聞き、いろいろな勉強会に参加していました。私が実践している楽しく勉強ができる方法を紹介します。

対象

• 勉強の仕方がわからない人
• いろいろな情報のインプット方法を知りたい人

考古学（こうこがく、英語: archeology）は、「人類」が残した「遺跡」から出土した「遺構」などの「物質文化」の研究を通し、「人類の活動」とその変化を研究する学問である。（Wikipedia）
つまりアーキテクチャ考古学とは、「先人」が残した「コード」から出土した「遺産・負債」などの「アーキテクチャ」の研究を通し、「プロダクト」とその変化を研究する学問である。（Akito.Tsukahara）
みなさん、こんにちはアーキテクチャ考古学者のAkito.Tsukaharaです。
この登壇では、新しく入社してくれたメンバー達へのオンボーディングをするために、考古学した（弊社のプロダクトのアーキテクチャを研究、文言化して、社内で勉強会）取り組みについて発表させていただきます！
考古学することには、「システムの理解とドメイン知識の向上」や「技術的負債の認知」をオンボーディングで伝えることで
新メンバーが少しでも楽に現場の開発に慣れてもらう意図があります。
この発表をご覧いただくことで以下の情報をお届けできます。
・考古学のやり方
・アーキテクチャに関する知識・ノウハウ
　・レイヤードアーキテクチャ
　・テスト設計　etc...
・オンボーディング資料の作り方
・社内勉強会でチームの巻き込み
など

発表者の会社では、複数の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の話はありません。

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を用いた設計・実装における勘所

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

主な対象

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

話すこと

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

話さないこと

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

目標

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

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

失敗しがちなポイント例

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

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

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

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

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

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

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

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

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

日頃、皆さんは何かしらの開発業務を行なっているでしょう。多くのメンバーで、プロダクトをどのように進めていくかよく話し合われ、同意のもと開発が進んでいる現場もあるでしょう。はたまた、少ないメンバーで、いろんなことが決め切らずに開発フェーズに入ることもあるかもしれません。

本トークでは、いずれの場合でもプロダクトを作る上で正義はあり、善行を行えることをお伝えしたいものです。
正義に基づく仕事なのか、仕事の結果善行となっているのか。本プロポーザルをお読みの方には、その2つにどんな違いがあるのかお分かりにならないと思いますが、ぜひともぼくのトークから仕事に反映できる何かを掴んでいただければ幸いです。

聞いていただきたいターゲットは以下のような方々です。

• エンジニアになってまだ1〜2年、1社目で今が良いのか悪いのかわからない
• 子供がいて、エンジニアリングと子育てになにか共通点がありそうと感じている
• 他のトークが技術ガチな話なので箸休め的に

PHPerのみなさんは金額計算などで、BCMath関数を使ったことがあるのではないでしょうか？
この関数郡は共通して「引数を文字列にする」という特徴があります。

ただし、floatをstringにキャストする際は少し注意が必要なので、正しくキャストするための方法をご紹介します。

本トークで話すこと

• 何故float型を四則演算すると計算結果がずれてしまうのか
• float型を単純に文字列にキャストするのは危険
• 文字列に正しくキャストするにはどうしたらいいのか

あなたのアプリケーションでは外部APIを参照していますでしょうか。
あるいは、あなたの作ったAPIを開発者に利用してほしいと考えていますでしょうか。

外部システムをプログラミング言語から使いやすくするパッケージはSDK(software development kit)と呼ばれることもあり、HTTPリクエストの発行やPHPクラスへのマッピングが主な責務になります。

基本的にはマニュアル通りの設定をしてメソッドを呼び出して使えるようにれば最低限使えるSDKができますが、開発やテストのしやすさという観点ではそれだけでは不足です。

このトークでは開発者とSDKユーザーの立場から、2023年現在で考えられるSDKの理想形とテスト手法について手短かに紹介します。

キーワード

• PSR-7, PSR-18, Asynchronous request
• 🙅🏻‍♀️ 不用意にGuzzleに依存しない
• HTTPlug Discovery

本稿の前提となる議論についてはPHPからのHTTPリクエスト (2016年版)にも掲載しているので、予習にどうぞ。

Laravelなどのフレームワークを使うと、安全なアプリケーションを素早く作ることができます。
一方で、処理が抽象化されていて簡単に書けてしまう分、よく理解せずに使うと思わぬところで時間を溶かしてしまったり、脆弱性を含むプログラムを書いてしまったりすることも多々あると思います。
そこで、このトークでは脱初心者を目標にLaravelが行っていることを一つひとつ追っていくことで、エラーメッセージを見た時に素早く対応できる状態を目指します。

対象者

• Laravel初心者
• Laravelを使った開発でエラーの解決に時間がかかる方

話すこと

• .htaccess
• index.php
• autoload
• routes/ での処理
• viewの表示の仕組み
• 404などのエラーページ表示の仕組み

話さないこと

• artisanコマンドの実装
  リクエストとレスポンスの部分を主に扱いたいため、開発に使う機能は今回は割愛します

ゴール

• Laravelがリクエストを返すまでの流れがわかる
• エラーメッセージを読んだ時に、どこを修正すれば良いか素早く判断できる

近年のWebアプリケーションに求められるUI/UXはどんどん上がってきており、SPAアプリケーションを構築する機会が増えてきていると思います。
「フロントとバックエンドが疎結合！」という甘美な響きの裏には、スキーマ管理・リポジトリ運用・API認証など様々なオーバーヘッドが存在しており、
中小規模アプリケーションの場合はSPAはコスト高で選択肢から外してしまったことはありませんか？

Laravel8から登場したInertia.jsを使うと、これまでのBladeを使ったシンプルなレンダリングと同じ手法で、お手軽にSPA開発が可能になります。
Controllerから変数をセット、レンダリングするビューを指定するだけで、認証やスキーマなどを意識せず、JavaScriptページコンポーネントへとデータが渡りSPAとして動作します。

この構成をInertia.jsの公式サイトでは「現代のモノリス」と呼んでいます。
APIを構築せず、密結合な構成にすることで生産性の向上を提唱する新しいWebアプリケーションの開発手法の1つです。

このセッションでは、そんなInertia.jsの概要の説明と簡単なチュートリアルをしながら、
実際のお仕事に導入した際に感じたメリット・デメリットも交えてご紹介していきます。

話すこと

Inertia.jsとは
LaravelでのInertia.jsの使い方と例
導入して感じたメリット・デメリット

テストコードのプルリクが来て意気揚々とレビューしてみると、こんなテストケースが書かれていたりしませんか？

• テストケース名が test_executeメソッド() としか書かれていない
• ひとつのテストケースの中で、複数のシナリオが確認されている
• なんでもかんでもデータプロバイダー
• テストケースの中にif文がやたら書かれている
• ひとつのテストケースを確認するのに、大量のデータセットが必要
• etc

こういったテストコードがレビューで飛んできたとき、自分はちょっといやだなぁと感じてしまいます。

本トークでは、なぜ上記のようなテストコードをいやだなぁと感じてしまうのか、何が問題になるのか、それに対してどのように書き換えればいいのかをコード例を交えながらお話しできればと思います。

私は学生時代に学園祭実行委員会に所属し、PHP を用いた学園祭 Web サイトの開発・運用や情シス業務に携わっていました。その頃の経験を振り返り、学園祭 Web 開発の過去と未来に触れつつ、一般のエンジニアでも他人事ではないような話をします。

こんな話を時間の許す限りします

• 学園祭 というドメインならではのチーム・プロダクトの特徴
• PHP での開発をどう学び、後輩に伝承するか
• 現代における学園祭 Web サイトの設計論
• 社会人エンジニアとなった今役立っている経験

参考リンク

関連する内容について、ブログエントリを公開しています：

• 学園祭のWeb開発を語る: 具象編1 講習会と砂場遊びで支える組織
• 学園祭のWeb開発を語る: 具象編2 開発体験・保守性を投げ捨てる
• 学園祭のWeb開発を語る: 抽象編 自分たちの責務をどう絞り、どう委嘱するか

2021 年 11 月、PHP の処理系と言語そのものの開発に一大転機が訪れました。

• PHP の様々な側面での近代化に関わってきたコア開発者 Nikita Popov さんの活動規模縮小
• それを契機とした The PHP Foundation の発足

The PHP Foundation は寄付を募り、PHP 処理系の実装と言語仕様の改善へ取り組むコア開発者へ資金を提供して、日中の仕事として PHP の開発を行えるようにする団体です。寄付が集まるほど PHP の開発が加速し、私達 PHPer がその恩恵を受けられることになります。
https://thephp.foundation/

すでに日本を含めた世界中から多くの寄付が集まり、The PHP Foundation によって雇われた数人の開発者によって、実際に多くの言語改善が成し遂げられました。このような PHP の開発事情をすでによく知っていて、所属会社からも寄付を行っている、という方もいれば、「PHP という言語自体の開発を生身の人間がやっていて、彼等がどう日々のご飯を食べているかが我々のビジネスに強く関係している、なるほどその発想はなかった」という方もいらっしゃるかと思います。

このトークでは The PHP Foundation の成り立ちと意義、これまでの活動内容をあらためて紹介し、「そういうわけで皆も会社のお金で The PHP Foundation に寄付をしよう！」というお話を、The PHP Foundation の関係者でもないのに外野から勝手に力強くやっていきます。