Form・Html ファサードは laravelcollective/html パッケージに含まれています。
このパッケージは放棄されており、spatie/laravel-html への移行が推奨されています。
私の関わるサービスでの使用箇所は約1,700箇所…！
移行ツール「Shift」で移行しましたが一筋縄ではいかず…

今回は laravelcollective/html の Shift による移行で、苦労して得た知見をご紹介します。

■ 内容

laravelcollective/html から spatie/laravel-html への Shift による移行方法
Shift でうまくできなかったところ
移行前後の違い
■ 対象

laravelcollective/html の移行を検討している人
移行ツール Shift がどういうものか知りたい人

このセッションのゴールは、オブジェクト指向の再認識です。

SOLID原則を世に広めた、アンクル・ボブことロバート・C・マーチンの新刊、「Functional Design」が登場しました。関数型ブームの影響を受けた現代のプログラミング言語から見ると、この本の登場はむしろ、遅すぎたと言ってもよいかもしれません。しかし一方で、私達は普段の経験で十分に、関数型の本質的な原理を理解したと言えるでしょうか。

改めて関数型とは何なのかを理解し、そこから逆説的に、次のようなテーマを深堀りしていきたいと思います。

• 関数型の支持者がOOPと呼んだ概念の的外れっぷり
• 計算機科学でオブジェクト指向をとらえようとした過ち
• 生成AIやオブジェクト指向と、21世紀の哲学の相性の良さ
• プログラマーと日本人はなぜオブジェクトをうまく説明できないのか

(ぜんぶ喋れるんかこれ!?)

ここ数年、LLM の進化とともに、RAG（Retrieval-Augmented Generation：検索拡張生成）の構築・利用が進んでいます。RAG の内側ではよくベクトル検索が使われていますが、ベクトル検索には RAG 以外にもいくつかの使い道があります。

本トークでは、ベクトル検索を理解するのに必要な事項と、PHP から利用する際のサンプルコードについて説明します。

• ベクトルとは
• 情報をベクトルで表現すると嬉しいこと
• 距離と類似度の種類と計算
  • ユークリッド距離
  • コサイン類似度
  • どれを使ったら良いの？
• ベクトル検索の使い道
  • レコメンド
  • セマンティック検索 etc.
• LLM の埋め込みモデルとベクトルストア
• ベクトルストアで近似近傍探索インデックスを使う
• pgvector-php を使ってベクトル検索を試す

現代はGitHub Copilotなどの生成AI開発支援ツールが普及していますが、簡単に使える一方で、「サンプルを生成して」等の単純な質問しかせず「ChatGPTで十分では？高いし！」という声も聞きます。

もったいないと私は思います！

チャット機能しか使わないのは確かに煩雑で「自分で書いた方が早い」と思うのも理解できます。しかし、ツールは進化を続けています。様々なUIや機能を活用し、AIとより良いコミュニケーションを取ることで、AIという相棒と共に、より効率的な開発をしませんか？

アイザック・アシモフの『鋼鉄都市』では、C（炭素＝人間）とFe（鉄＝ロボット）がバディになります。最初はR(obot)を嫌っていた人間の主人公も、最終的にロボットとバディとなりました。
それは小説ですが、SWEの皆さんも、人でない生成AIと良きバディになれると思います。共にC/Feの文化を築きましょう！

カンファレンス等では話を聞くことも多いテストコード。テストコードをかけると、それが命綱のような役割となり、安心してコードの変更を行えるようになります。

ですが、歴史の長いソフトウェアでは、様々な経緯からテスト環境が導入されていないこともあります。

本トークでは、Laravelなどのフレームワークを入れるのではなく、ゼロからテスト環境を導入する方法を解説します。

• composerでphpunitをインストール
• autoloadの設定
• phpunitの設定ファイルの記述

このトークを通じて、みなさんも関わっているプロダクトで、テストコードのゼロイチに挑戦してみませんか？

話さないこと

• 良い単体テストコードの書き方

「テスト(自動化テスト)を書くのが苦痛」という人がいる一方で
「書いた方が開発が早くなる」という人もいます。なぜ？

「楽に仕事を進める」を追求したに過ぎないのです
「全部そうしよう」と思わず「楽に書けそうな所なら書く」という面もあるでしょう

肝となるのは
「必要なものを考える↔コードを書き上げる」の一連の動きの内で
何をどう切り取り、何で仕事を担い、どんな順番で実行し…の捉え方＝マインドセットです
(ちょっとだけ道具の使い方も！)

プログラミングの捉え方をちょっと変えて
「テスト好きじゃない」から「書いた方が早い」への一歩を踏み出すためのトークをします

こんな人に

• テストが苦手だ、嫌々やっている
• テストに興味があるけど、どこから始めれば良いのか分からない・環境がない

伝えたいこと

• テストで楽をする・早くなるってどんな感覚？
• やりやすい所から始めよう！！

「複雑で辛いコード」という概念は確かに存在するものの、
その正体がどこにあるか…？を上手く説明できないという事態も、しばしば発生するのではないでしょうか。
プログラミングは往々にして「感覚」「センス」も重要なのは百も承知。
でも、可能なら地に足のついた説明を加えたいですよね。

色々な分析・説明の手法を頭の中の引き出しに入れておくと便利です。
そんな物差しの1つの例として、「LCOM」があります。凝集度を数量化するものです。
定義をしっかり記憶していなくても、
そのコンセプトは、目の前のコードで「何が起きているか」を感じるための大きな助けになります！

このトークでは、
「ざっくりLCOMってなに」を話し
「手書きで図にしてみると分かりやすいね、似た考えを普段から使えそう」を感じてもらい
「抽象化やパターンと絡めて、リファクタリングに取り入れてみるとこんな感じに」をお届けします。

最近またオレオレフレームワークをつくりました、私のフレームワークのポリシーは長生きができることです。

今回私が一晩で作り上げたフレームワーク()をベースに、どのような部分を意識することでコードが理解しやすく、長生きができる工夫をしているかをお話ししたいと思います。

機能が満載のライブラリやフレームワークに慣れている皆様は、「こんな素朴な規約やフレームワークは使いたくない！」と思うかもしれませんが、私は誰でもわかり、5年10年生き延びるフレームワークにしたいのです。

本トークはオレオレフレームワークにかぎらず、特定のライブラリと密結合せずデカップリングするようなコードを書く際にも役立つと思います。

皆さんも手のひらに収まるようなコードにして、暗黙を避け、ジョインした人がすぐにコードをかきはじめられるようにしてみませんか？

今では多くのPHPerが利用している静的解析ツールのPHPStan
このPHPStanについて踏み込み、上手く活用する方法とアンチパターンについて以下を参考にお話します。

• PHPStanの基礎について
• 静的解析の強さについて
• 既存プロジェクトへの導入するコツ
• レベルに囚われずルールを追加する方法
• PHPStanにとって嬉しいコードの書き方について
• 導入におけるアンチパターン
• PHPStanが悪魔に変わる瞬間

「PHPは脆弱」

PHPerの方ならこの言葉一度は聞いたことがあるでしょう。

これなんでなんでしょうね〜〜！？！？！？わかるひとーーーー！！！！？？？？

ということで、本トークでは「PHPは脆弱」と言われるようになった原因について以下のようなワードに触れつつ、歴史から振り返ってお話をします。
そして、その内容を踏まえ、我々は「どのようにプログラミングをしていけば、より安全なソフトウェアを開発していくことが出来るか」について自分なりに述べさせていただきます。

• PHPの実行形態・言語の特徴
• 静的解析
• IPA
• ラスマス・ラードフ
• PHP財団
• 標準化
• CVE
• セキュリティ
• エンジニアバブル

普段PHPを利用している方も、これから書いてみたいという方も楽しめるトークを目指します。

皆さん、チームを分割してみたけど、結局また一つにまとまっちゃったことありませんか！？

チームが分かれれば効率も上がる、役割も明確になる…なんて思っていたのに、なぜかチームが再び一つに引き寄せられてしまったんです。

その原因、実は「コンウェイの法則」にあったんです！

このLTでは、どうしてチームを分割したのに再統合が起きたのか、そしてその結果として何が得られたのかを赤裸々に語ります。

私たちが直面した課題や学びをシェアして、みなさんの組織設計にも活かしてもらえたら嬉しいです！

ソフトウェアエンジニアには抽象化の能力が重要と言われます。
では実際に抽象化とはどのような能力なのでしょうか？

実際の事例を交えながら、抽象化を理解し、実務に活かせるようにします。#

話すこと

• 抽象化と具体化とは
• 抽象化のメリット
• 現実で身につける抽象化の階層
• 抽象と具象の往復とは
• ソフトウェアと抽象化

話さないこと

具体的なソフトウェアの実装における抽象レイヤーの話

可読性のためにコードのネストを浅くすることはとても良いプラクティスです。
ガード節はネストを簡単に解消できる手法として広く勧められていますが、途中リターンを多用することに問題はないのでしょうか？

このトークでは、ガード節を使うメリット・デメリットを詳しく分析し、さらに可読性を高めるために考案した新しいテクニックを、具体的な例を交えながらご紹介します。

ネストが浅くて読みやすいPHPコードの作成にきっと役立つ情報をお届けします。

概要

モノリシックかつレガシーな肥大化したPHPアプリにお悩みではありませんか？１０年近く長年運用されてきたアプリケーションでは、技術負債による開発・運用上の問題に苦しむことが多いのではないでしょうか。これらの問題は短期で簡単に解決できないケースがほとんどです。
そこで、本発表では、「改善」の手立ての一つとして、主にAWS Lambdaを活用したアーキテクチャの変更や機能分割を行うことで得られる開発運用効率化について実体験をもとにご紹介させていただきます。

対象者

• レガシーなモノリシックPHPアプリを運用しているエンジニア
• クラウドサービスの導入・活用を検討されている方

得られること

• モノリシックなレガシーアプリの課題を理解できる
• 効率的な運用のための具体的なアプローチを知ることができる

自分の会社の製品には多くのサードパーティサービスが組み込まれています。
それらのサードパーティサービスは頻繁にバージョンアップするので、よくパラメータを更新する必要があります。例えば base URL や secret など。
HashiCorp Vault を使用して、ララベル向けの Config 管理インターフェースを実装することで、ゼロダウンタイムで Config の変更が可能なだけでなく、エンジニア以外の同僚も一緒に Config の管理できます。

連想配列に全てを詰め込んで旅をさせるのは良くないとは分かりつつ、
今まで巨大な連想配列をゴリゴリ実装していたチームが、配列からの脱却への一歩に挑戦しました。
完全な配列脱却は難しかったものの、バランスをとったリアルな挑戦ができたのでお話しします。

話すこと

• 配列で書いていた時代の実例、課題、デメリット
• ファーストクラスコレクションとは
• 配列からの脱却に⁠ファーストクラスコレクションを採用した理由
• ファーストクラスコレクションに感じたメリット/デメリット
• デメリットをカバーするために生み出した、ファーストクラスコレクション亜種

郵便番号とは、当たり前に都道府県・市区町村が特定できるものだと、そう思っている人はいませんか？
まさか「複数の都道府県にまたがる郵便番号」なんてあるわけない、そう思っている人はいませんか？

そんな罠にはまった私が、郵便番号に関する実装をする際に気を付けるべき知見を、クイズ形式で紹介します！

ご存知の通り、レビューとは「講評」「批評」という意味です。
そのためコーディングにおけるレビューも、どうしてもレビュワーから実装者への一方通行コミュニケーションになりがちな側面を持っています。

しかしレビューとは、実装者とレビュワーが解釈をすり合わせる場であり、
双方向のコミュニケーションをしてこそ、漏れなく効率的なすり合わせができると私は思っています。
今回は私がPRレビューを双方向コミュニケーションの場にするためにしていることを、3つお話しします。

• 些細な違和感を逃さない[Q]と[MEMO]
• レビュー修正者を迷わせない効率的レビュー
• チームメンバーの癖を把握した、メンバー特化型レビュー

テストを書くことにもだいぶ慣れてきましたが、いまだに嫌で仕方ないものがあります。それがデータプロバイダです。

データプロバイダを書くのは面倒くさい。本当に本当に面倒くさい。
というのもリリース恐怖症の私は、テスト対象のありとあらゆる条件やパスを通したくなります。
「いや〜書かなくても大丈夫だろうけど、怖いし一応書いとくか…」を繰り返すうちに、どんどんテストパターンが増え、データプロバイダが膨大になります。

ここでは、私をそんな無限コピペ地獄から救ってくれた「差分だけデータプロバイダ」をご紹介します。
同地獄に陥っている方の一助となれば幸いです。

⁠対象者

• いつもデータプロバイダが太りがちな方
• ツールなど使わず手動で、大量のパターンをテストしなければいけない方
• データプロバイダを書くのが億劫で仕方ない方

抽象構文木:ASTの名前は、PHPStanやRectorの普及もあり、少し身近な存在になってきました。

しかし「コンパイラでもない人間の我々が、なぜ喜ぶのか？」と思う人もいるはず。
名前や、チラッとだけ概念は知っている。けど、何をもたらしているのか──

そこで、ASTの概念の応用例に触れてみたら、その世界に入門しやすいのではないか！！というトークです。
「こういう事もできる(応用)」「そのために(基礎概念)」を話します。

例えばajthinking/archetypeはプログラマブルな「コード書いてくれる君」です。
ソースコード生成が「スタブの文字列置換やTwigのレンダリング」に頼らず出来るようになる！
じゃあ、その内側のどこにASTがいるんだ！

応用例から「逆に入っていく」アプローチで、ASTと少し仲良くなることを目指します。