このセッションではPHPで作成したアプリケーションをVercelにデプロイする方法を紹介します。

Vercelは「Vercel のフロントエンド クラウドは、開発者にフレームワーク、ワークフロー、インフラストラクチャを提供し、より高速でパーソナライズされた Web を構築します。」(X：@vercelより引用)で、PHPのイメージはありませんが、PHPのアプリケーションをデプロイすることができます。

また、VercelにはVercel PostgresというPostgreSQL(データベース)を提供するサービスもあります。PHPとVercel Postgresを用いてアプリケーションを作成し、Vercelで公開することができます。

このセッションでは、VerceでPHPを用いたアプロケーションを公開する方法とVercel Postgreの紹介をします。

本セッションでは、同じ会社のメンバーに登壇依頼、カンファレンスのスポンサー窓口担当や共にカンファレンスの登壇や参加準備することで職能間の境界を越えて交流することができ、私の社内でのコミュニケーション量が増加してきた話をします。

私は、社内外で勉強会をいくつか企画し開催してきました。開催した勉強会のテーマはそれぞれ異なっており、私が開催したいと思った勉強会を勢いで開催しています。

しかし、最初は私が開催するとは思っていませんでした。私が所属している会社は職能ごとにチームが分かれており、プロジェクトによっては他の職種のメンバーと話すことがないこともあります。
しかし、今では職種が異なるエンジニアとも勉強会をきっかけに交流し、関係を継続することができています。

本セッションを通して、自身の技術領域外の勉強会を開催することで得られる職能間の境界を超える楽しさについてお話しします。

ソフトウェア開発では、仮説検証を繰り返す中で「作ったけど使わなくなった機能」が必ず発生します。
しかし、こうした不要なコードを削除するのは、稀によく後回しにされがちです。

• 消さなくても動作に影響がない
• 消したときの影響範囲が不明でリスクがある
• そもそもコードが整理されていないので、どこを消せばいいのかわからない

こうした理由からコードが積み重なり、開発スピードが落ちたり、認知負荷が上がったりしていませんか？

本トークでは「捨てやすいソフトウェア設計」をテーマに、

• 「10分で機能を削除できる」設計の考え方
• コードを整理し、機能単位で管理するディレクトリ構成
• チーム全体で「捨てる文化」を育てる方法

をお話しします！

仮説検証をスムーズに回し、変化に強いソフトウェアを作るために、「捨てやすさ」について一緒に考えてみませんか？

オープンソースソフトウェア（OSS）の開発や提供、利用促進、情報交換、および機能や品質の維持、改善等につながる活動はなぜ楽しく感じられるのでしょうか。OSSを作ったり、使ったりすることを通して、同じ興味や関心がある人たちと交流しながら、さまざまなことを知り、いろいろなことが分かるようになるからではないでしょうか。過去に経験したOSS活動におけるエピソードを紹介しながら、OSS活動を通して得られる楽しさの中身についてこのトークでは話してみます。

「◯◯を作るための設計をしてください」と言われて、どんな事を思い浮かべますか。どんな事から取り掛かるでしょうか

大きな意思決定は、高度な知識・技量を持つ技術者に委ねられるものです。
場合によっては「設計はリードや先輩の仕事だ」なんて感覚(あるいは経験っとして)を持つ人もいるかも知れません。
しかし、メソッドの切り方や変数名を1つとっても設計的な意思決定が関わっていると言えます。

──この設計というやつは、いったい何なのでしょうか？
このトークでは、これから中級者を目指す人をメインの聴者に想定し、
「設計ってなんだっけ」に焦点を当てた話をします。

具体的な戦術・パターンより以前にあるはずの、「設計をすること」の意義や必要性、効果を整理していきましょう。
誰かと「設計をしましょう」と言った時に
お互いの話したい事がチグハグにならないよう、目線を合わせていくための材料を提供します。

テストコード実装によるアプリケーションの実装設計や中長期の運用メンテナンスに変化が出た話をします。
当初、ファットコントローラーや行数の多いメソッド、ライブラリへの依存性高い設計などが原因で、メンテナンスしにくいPHPアプリケーションを運用していたチームがテストコードの実装から技術負債を徐々に解消していけるようになりました。
理由は「テストコードを踏まえた設計」をするようになったこと。
挙げた課題解消に向けてどのような実装・設計の変化が起きたかリファクタリングの具体例や、テストコード導入によるコード設計の変化を紹介します。
またテストコードを整備したアプリケーションを立ち上げた事でPHPやフレームワークバージョンアップへの適用性、テストコード実装スピード向上やコードレビュー時のチームコミュニケーションの変化についても語ります。

概要
皆さんはPHPにおける型にはどのようなイメージをお持ちですか？
楽？バグの温床？そもそも気にしたことはない？
本トークではPHPを通じて「データ型とは何か」から躓きやすい「PHPの型の相互変換」などについてお話しします。

ターゲット
経験年数5年くらいまでのPHPer初級者 ~ 中級者の方
改めてPHPの型について基本を学びたい方

詳細
本トークでは「PHPの型」をテーマに、型の基本概念からPHP特有の型システムに至るまでを解説します。
具体的には以下の内容を取り扱います。

1. 型とは何か
2. 動的型付け言語と静的型付け言語の違い
3. PHPの基本的なデータ型
4. 複合型と特殊なデータ型
5. 型の相互変換
6. 型の確認・検証

上記を通じて、参加者はPHPの型を深く理解できるので、PHPと少し仲良くなれるかも知れません。

ソフトウェア開発が「複雑で曖昧なもの」であるという前提で、
我々は「いかに分かりやすくて心地よいコードを書いていくか」に取り組む必要があります。

数多くある「◯◯原則」「◯◯戦術」「◯◯パターン」を事細かに覚えて、使いこなさなければならないのか・・？
─なんだか、ただでさえ「難しくて大変」なことに「小難しくて堅苦しい」ものを上乗せしている感じもしてしまいます。
よりシンプルに、頼りになる思考や感性が欲しいものです。

その意味で、あらゆるものに先立つのは「抽象」だと考えます。
それによって「柔軟さ」と「問題の分離・分解」を押し進める力が手に入るからです。

このトークでは、プログラミングの中や外にある「抽象的に考える」の場面を例示しながら、
それがどのように使い手を助けているのかを紐解きます。
「抽象とか具体ってもっと気軽に考えて良いんだ」と思えるようになるきっかけを提供します。

「よく出来ているツールを分解して、自分なりにガラクタを再発明してみたら、気楽だし楽しかった」という話をします
写経だけだと身に付く感じがしない、けどゼロから何かを作るにはネタが思いつかない…という人でも、とっつきやすい学習方法だと感じています。

こんな人におすすめ

• 普段使っているツールに「詳しくなる」きっかけを探している
• 設計力や実装力などの地力を向上したい・勉強法を探している
• 何かおもしろソフトウェアを作ってみたいが、発明のアイディアがない！

こんな話をします

• 再発明のガラクタ作りってどんな事をするの？
• 「やってみた」話
  • 実例をもとにして、「こんなものを作りました」の紹介
  • そのために「どう始めたか」「どう進めたか」
• この学習方法<遊び>で、身につく力
  • コードリーディングの力
  • エッセンスを理解する、抽象的に捉える力

新卒から6年間所属した部署から大異動で全く別のチームに配属された先には鳴り響くアラートの日々が待っていました。
アラートについて見ていくと異動先のチームには、以下のような問題を抱えていました。

• アラートの詳細を詳しく見なければ問題がないことを判断できない
• アラートの判断は属人化している
• ほとんどのケースにおいて問題ないアラートが飛び続けている
• 最初に監視を設定した人はすでに社内におらず、意図がわからない
• メンバー間のアラートに対する認識齟齬

これらに対して、一つ一つ向き合って出してきた答えについてお話します。
聞いて欲しい方

• 新たに配属されたが、アラート対応ができなくて悔しいと思ってる人
• アラート対応に課題感を持っている人
• 一緒に見直していく仲間を増やしていきたい人

本トークでは自己ドキュメント化をテーマに、それが内包する楽しさについて紐解いていきます。

自己ドキュメント化は開発者の知的好奇心を満たすプロセスであり、コードを通じて思考を整理し、意図を明確に表現する行為そのものが、新たな発見や学びをもたらします。それは単なる効率化の手段にとどまらず、創造性や知的満足感を生むプロセスであることに疑いはありません。

本トークでは自己ドキュメント化の具体例をPHPコードを用いて示し、その具体的な手法について解説いたします。さらに、自己ドキュメント化に楽しさを感じにくくなる場面にも注目し、その要因を分析します。そして、それを克服し、継続的な好奇心と満足感を支えるための環境づくりについても考察します。

この取り組みを通じて自己ドキュメント化に潜む楽しさをより深く理解し、開発が個人やチームにとって豊かで意義のある活動へと昇華することを目指します。

データベースの寿命はアプリケーションより長い。
では、どのようにデータベースの寿命を伸ばしていけばよいのでしょうか？
そのコツは 変化に強い データベース設計にすることです。

そこで10年以上のサービスの寿命に耐えられるようなテーブル設計の勘所をご紹介します

お話すること

• RDBMSを利用して正規化をするときに大切なこと
• デプロイでデータベースを壊さないコツ
• 変更に強い設計

話さないこと

• 正規化の具体的な方法
• 既存テーブルのリファクタリングのやり方
• RDBMS以外の設計の話

古いコードベースを読み解く作業はしばしば「ソフトウェア考古学」と呼ばれます。
ソフトウェア考古学を通してサービスの歴史から当時の設計思想や変化の過程を知ることは、良い設計を体験し、学べる貴重な機会です。

本トークでは、新卒5年目エンジニアである私が、20年以上稼働し続けるWebサービスの改善に向き合う中で試行錯誤し学んだことをお話しします。

お話すること

• 古いコードベースを読み解き改善を行った事例とその課題
• 複雑なコードベースを効率良く理解するための「鳥の目・虫の目」の考え方・具体的な進め方
• ソフトウェア考古学の経験から学んだ理解しやすいコードを書くコツ・あると嬉しいドキュメントとは？

聴いてほしい人

• コードベースが古い環境で悩んでいる人
• 歴史のあるコードを改善したい人
• 複雑なコードベースを効率的に理解する方法を知りたい人

PHPではtry-catchを使った例外処理が一般的ですが、「この例外はどのレイヤーで処理すればいいのか？」や「どの場面で例外を使うべきなのかが曖昧だ…」と感じたことはありませんか？
例外の種類や扱い方が曖昧だと、混乱しますよね。
この課題に対するヒントとして、Rustなどの言語で採用されているResult型の考え方があります。

Result型は、失敗が起こり得るということを型として扱い、例外に頼らずエラーを管理する手法です。
これにより、エラーの種類や処理責任が明確になります。
このセッションでは、Result型をPHPに応用する方法を実装例を交えて解説します。

取り上げる内容：

• エラーの種類の整理方法
• Result型の基本的な考え方とPHPでの実装方法
• try-catch採用プロジェクトでも活かせる学び

エラー処理を改善するヒントをお持ち帰りください！

「テストがないコードはレガシーコードだ！」
Webアプリケーション開発においてテストコードが書かれることは一般的になってきました。

ですが、テストにかかる時間は適切でしょうか？ テストにかかる時間は開発スピードに大きな影響を及ぼします。
本トークでは自動テストを高速化するための考え方やテクニックについてお話します。

想定観客

• テストにかかる時間を短縮したい方

お話しすること

• Google提唱の「Test Sizes」を取り入れて、テスト対象をCIとローカルで変えるテスト戦略
• テスト実行の並列化 (Makefile, xargs, paratest)
• CIをジョブ分割して体感速度を上げる
• テスト時も割と効くXDebug無効化 & OPcache有効化

「カンファレンスは初心者にとってハードルが高い」「カンファレンスぼっち参加は心細い」
そんな風に感じたことはありませんか。

2024年、私は各地のPHPカンファレンスへ継続的に参加しました。
PHP歴半年、1人での遠征。最初は私も上記のような不安でいっぱいでした。

このトークでは、下記２つについて話します。
・私が不安を乗り越えてカンファレンスに参加するために持っていたマインド
・私がPHPコミュニティの熱狂へ飛び込んで得たもの

このトークを通して、勇気を持ってPHPカンファレンス新潟に参加した方が、またカンファレンスへ足を運んくださることを目指します。

【参考】
今年参加したPHPカンファレンスを振り返る
https://speakerdeck.com/kousukeosanai/jin-nian-can-jia-sitaphpkanhuarensuwozhen-rifan-ru