考古学（こうこがく、英語: 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 の組み合わせで現在動作しています。

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

主な対象

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

話すこと

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

話さないこと

• 特定の言語でしか使えない 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型を単純に文字列にキャストするのは危険
• 文字列に正しくキャストするにはどうしたらいいのか

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

対象者

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

話すこと

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

話さないこと

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

ゴール

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

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

• テストケース名が 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 の関係者でもないのに外野から勝手に力強くやっていきます。

2023年4月時点で、CakePHPは5.0βの開発が進行中です。
およそ3年ぶりのメジャーバージョンアップとなり、PHP7へのサポートを終了する最初のバージョンとなります。
コードネームはChiffon(シフォンケーキ)と言います。

まだまだ機能のスコープは安定しませんが、どんな変化が予想されて、使い勝手はどう変わるのでしょうか？
このトークでは、カンファレンス当日までのなるべく最新の情報を取り込んで、開発状況・個人的な所感や予想について共有します。

話すこと

• CakePHPの4.3辺りからの「どういう変化が起きているか」のおさらい
• CakePHP5.0で計画されている変更点
• それらを総じて、「このFWはどういう方向に向かおうとしているのか」の所感

テスト書いてますかー！と聞けば、書いてますよー！と元気に答えてくれる人って多くなっていそうですよね。
では、得意ですかー！とか、他人に教えられますかー！とかって聞くと・・？難色を示す人も多いのではないでしょうか。

「テストを勘で書いてきたし、書けるようになってきたけど、そろそろ品質とか理論とかを学びたい」という人に向けたトークをします。
ただし、これは非常に深く広大な話題だと思うのですよね。
そこで、単体テストにフォーカスを絞って、「考え方を身に着けたり、引き出しを増やすために役立ちそうな情報はないのか？」に応える「手引き」となるようなトークをします。
どういう課題を持っているか・どういう知識を身に着けたいのかというケース別に、処方箋となりそうないくつかの書籍や情報リソースを紹介します。

想定対象者

• 「普段の仕事では単体テストを書いている」くらいのレベルにはあるけど、自分の書くテストに自信がない人
• 「テスト中級者」よりも手前のレベル感だなぁ、と感じている人
  • 「全く書いたことがない」という人はスコープから外れます！

話すこと

• テストについての(一般化された)知識、理論を学ぶための情報
  • 主に単体テスト
• 日頃から「テストをスラスラと書けるようにする」ための学び方、鍛え方

話さないこと

• PHPUnitなど、特定のテスティングフレームワークの利用者練度を高めるためのtips
• テストの「動かし方」やテスティングフレームワークの内部構造など、実装に関する話

【前口上】
ありがとうPhpStorm、寛容で叡智に富んだあなたがいてくれて、私のPHPはどんどん良くなっていく───
コードエディタの領域だけではない、ソフトウェア開発を幅広くサポートする強力なツール・機能群。静的解析ツールやテスティングフレームワークといったPHPコミュニティの資産との力強い連携。そして、あらゆる面でコードのクオリティを底上げしてくれる静的解析機能！！

今日では、こんなにも進歩した相棒によってPHPの開発が支えられております。
便利で馴染み深いツールだからこそ、しっかり使いこなして普段の開発をより心地よく・生産的なものにしたいですよね。

【本題】
そんな事を感じながらも、あなたはPhpStormのInspectionについて、どのくらい把握できていますか？
当たり前のように目にしており、時には自分で調整をしてみるものの、あまり網羅的に内容を観たことがない・・という人も少なくないのではないでしょうか。

本トークでは、PHPについてのInspectionを全体的に眺めてみつつ、現場で実践的に活用するための方法を共有します。

主に話す内容

• PhpStormのInspectionってどんなものがあるの？
• ちょっとした付き合い方のコツ、個人やチームで上手く使う
• 自作のインスペクションを追加する

Google Apps Script（以下、GAS）とは Google が提供するローコードプラットフォームです。

普段 JavaScript を書くのほぼ同じ感覚でコードを書いて実行できますが、単なる JavaScript 実行環境にとどまらず Google の提供する各種サービス（スプレッドシートやフォーム等）との連携を容易に行えたり、動的な Web ページを表示できたりと、まさに「ローコードプラットフォーム」と呼ぶにふさわしい機能を備えています。

何が正解かわからないビジネスの世界において、誤った方向性でプロダクトを作り込んでしまうことを避けたいもの。
そのためにコストをかけずにプロトタイプを作って仮説を検証するのですが、GAS の備える特性はそのサイクルを回す際に強力な助けとなります。

本トークでは、そんな仮説検証を回すため知っておくと役に立つ

• GAS でできること
• GAS を使うときのコツ、Tips
• GAS の限界、使うべきでないところ

についてお話します。

フロントエンドやバックエンドのような技術的関心事で担当領域を区切るのではなく、プロダクトが価値を提供するために技術面全般へ責任を持つ「フルサイクルエンジニア (full-cycle developer)」という考え方があります。

本トークでは、フルサイクルエンジニアという働き方についての説明と、私がフルサイクル開発者として5年ほど仕事をしてきた中で「良い仕事」をするために意識していることをご紹介します。

対象観客

• フルサイクルエンジニアという考え方に関心があるかた
• フロントエンド/バックエンド/インフラだけを専門的にやっているがこれで良いのか？という悩みを抱えているかた
• プロダクトについてもっと責任を持ちたいと考えているかた

話すこと

• フルサイクルエンジニアとは何か
• フルスタックエンジニアとの違い
• 専門性についての懸念
• どうあれば「良い仕事」と言えるのか
• 「良かった」とフィードバックを貰えた仕事例