レギュラートーク(30分)

C/Fe の時代 :人とAIがバディになる第一歩

uzulla uzulla

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

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

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

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

3
レギュラートーク(15分)

PHPでテストコードのゼロイチをやってみよう

aki_artisan あかつか

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

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

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

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

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

話さないこと

  • 良い単体テストコードの書き方
4
レギュラートーク(30分)

「複雑なコード」を図にして考える

o0h_ きんじょうひでき

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

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

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

4
レギュラートーク(30分)

粗食なオレオレフレームワークで、長生きしよう!

uzulla uzulla

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

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

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

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

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

6
レギュラートーク(30分)
U25(登壇時に25歳以下) 初登壇(これまでカンファレンスで登壇経験なし)

PHPStanを味方にする術・敵にするアンチパターン

malsuke096 まるすけ

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

  • PHPStanの基礎について
  • 静的解析の強さについて
  • 既存プロジェクトへの導入するコツ
  • レベルに囚われずルールを追加する方法
  • PHPStanにとって嬉しいコードの書き方について
  • 導入におけるアンチパターン
  • PHPStanが悪魔に変わる瞬間
4
LT(5分)
初登壇(これまでカンファレンスで登壇経験なし) 東海勢(出身or在住)

チームを分割したけど、ものすごい引力(コンウェイの法則)によりチームがまた一つになった話

inu_shunta いちかわしゅんた

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

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

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

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

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

1
レギュラートーク(15分)
初登壇(これまでカンファレンスで登壇経験なし) 東海勢(出身or在住)

ガード節に頼らない!ネスト削減のマル秘テクニック

ひろふみん

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

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

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

1
レギュラートーク(30分)
初登壇(これまでカンファレンスで登壇経験なし) 東海勢(出身or在住)

レガシーPHPアプリを改善する手立て~AWS Lambdaを活用した改善の実践方法~

darupu_tech だるぷ

概要

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

対象者

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

得られること

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

Vault でララベルの Config を管理する

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

2
レギュラートーク(30分)
東海勢(出身or在住)

ファーストクラスコレクションで、配列からの脱却へ一歩前進!

saku_rye さくらい

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

話すこと

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

郵便番号から都道府県は一意に特定できない罠をご存知か

saku_rye さくらい

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

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

2
LT(5分)
東海勢(出身or在住)

PRレビューとは、双方向のコミュニケーションである

saku_rye さくらい

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

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

  • 些細な違和感を逃さない[Q]と[MEMO]
  • レビュー修正者を迷わせない効率的レビュー
  • チームメンバーの癖を把握した、メンバー特化型レビュー
1
LT(5分)
東海勢(出身or在住)

差分だけデータプロバイダのすゝめ

saku_rye さくらい

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

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

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

⁠対象者

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

Edit PHP files programmatically feat. AST

o0h_ きんじょうひでき

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

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

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

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

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

3
レギュラートーク(30分)

「Promiseって何だ!分からん!!」覗いて作って遊んでみよう

o0h_ きんじょうひでき

Promiseについて、「分からん!」から「そんなものもあるんだ」を経て、「そういう風になっていて、そう動くのか」に至るためのトークです
PHPによる実装を試みます

  1. Promises/A+の世界観や、概念レベルの「何を課題とし、どう解決を試みるパターンなのか」の共有から入り
  2. guzzlehttp/promisesreact/promiseといったPHP実装を参考にしながら
  3. 低機能で愚直なPromiseオブジェクトを生み出していきます

このトークで得られるもの

  • Promiseについて知る
  • 「PHPでできること」「PHPっぽい実装」について知る

あまり話さない

  • ライブラリ自体の詳細、活用法
1
LT(5分)

tblsから始めるDBスキーマ可視化入門

takeokunn たけてぃ

概要

PHPでWebアプリケーションを作る際、ほぼ全てのケースでデータ永続化の為にデータベースを利用するでしょう。
長年運用していくにつれ、テーブル数やカラム数の増加によって、認知コストやコミュニケーションコストが増加する一方です。
これらの負荷を下げる為に「DBスキーマを可視化する」ということは非常に有用であり、tblsは継続的な運用に耐えうるだけの機能を持ち合わせています。

本トークではtblsを用いたDBスキーマ可視化の実例を上げつつ、具体的なツール導入とCI設定の方法を紹介していきます。

このトークでお話すること

  • tbls紹介
  • 運用例紹介
  • tbls新規導入と基本的な設定
  • GitHub Actions活用方法
2
レギュラートーク(15分)

Phpactorから学ぶLanguage Server Protocolの仕組み

takeokunn たけてぃ

概要

Language Server Protocol (LSP)は、2016年にMicrosoftが発表したJSON-RPCベースのプロトコルです。
LSPはモダンなテキストエディタなら必ずある機能(e.g. 定義ジャンプ)を提供していますが、一番の魅力は特定のテキストエディタに依存しない形での実装になっていることです。
これにより各テキストエディタでの実装の必要がなくなり、エディタ選択の自由度が飛躍的に高まりました。

PHPの言語サーバ実装はintelephenceとPhpactorがメジャーです。
本登壇ではPhpactorの実装に触れつつ活用テクニックを紹介していきます。

このトークでお話すること

  • LSPの台頭とLSP前後のテキストエディタの変化
  • プロトコル解説とLSPがサポートしている機能の紹介
  • PhpactorとPHPStan拡張などの便利機能紹介
3
レギュラートーク(30分)
初登壇(これまでカンファレンスで登壇経験なし)

セルフケアとレジリエンスで強くなる:継続的に働くためのメンタルケア

DPontaro DPon

メンタルは崩れると業務のパフォーマンスに大きな影響を及ぼします。
比較的メンタルが弱い私が継続して業務に携わるため実践してきたセルフケアやレジリエンスと言われる回復力の鍛え方をお話します。

聞いてほしい方

基本的にどなたでもではありますが。

  • 若い方(早めに身に着けておいて損はない)
  • メンタル弱い自覚のある方

お話すること

  • メンタルが不調になる要因
  • 実践してきたセルフケア
  • レジリエンスの鍛え方
  • 実践したことにより得られた業務での成果

得られること

  • メンタルが不調になりがちなときの対処法を学べる
  • 業務でのパフォーマンスを安定させるためのセルフケアのコツ
  • 落ち込んだときからの回復力(レジリエンス)の向上方法
  • 長期にわたりモチベーションを保つための具体的な戦略
4
レギュラートーク(30分)
初登壇(これまでカンファレンスで登壇経験なし)

レガシーアプリケーションの検索処理をOpenSearchで改善

DPontaro DPon

年月を経たレガシーなアプリケーションの検索処理は、肥大化したロジックによりパフォーマンスが劣化しがちです。本セッションでは、実際に直面した検索遅延を、OpenSearchを活用して改善した実例をもとに、選定理由から実装の課題、実際の効果までをお話します。

ターゲット

  • OpenSearch導入を検討している方
  • レガシー環境でのパフォーマンス改善に悩む方

お話すること

  • OpenSearchの概要
  • 社内で抱えていた課題
  • 選定理由
  • 実装時の躓き
  • 実装後の効果
  • 今後の課題

何が得られるか

  • OpenSearchの強みと効果
  • レガシーな環境での落とし穴
2
レギュラートーク(30分)

PHPでアクターモデル Phluxorを利用した分散システム入門

seike460 清家史郎

PHPカンファレンス沖縄2024にて @ex_takezawa さんのアクターモデルの話を聞いて衝撃を受けました
https://speakerdeck.com/ytake/understand-and-experience-the-actor-model-in-php

今回はPHPでアクターモデルを実現できる @ex_takezawa 作のPhluxorに入門し使用感と分散システムの優位性を探ります
https://phluxor.github.io

利用者の目線からPhluxorを使用する上での必要な前提知識や実際のハマりポイント、感じたメリットなど含めて分散システム入門します

より皆様に近い立場からの分散システムの実際の体験を共有し、少しでも分散システムが身近になることを目指します

  • 想定聴講者
    • 分散システム初心者
    • 分散システムの事を知らない人
4