みなさんのプロジェクトは、どのようなソフトウェアアーキテクチャを採用していますか？
明確なアーキテクチャが決まっておらず、各メンバーが異なる設計をしているプロジェクトも少なくないかもしれません。
私たちのプロジェクトもその傾向にありました。

本セッションでは、プロジェクトのリニューアルを機にオニオンアーキテクチャを導入した経験について、以下の内容を中心にお話しします。

• オニオンアーキテクチャを採用した理由
• Laravelにオニオンアーキテクチャを導入する際の具体的な手法
• Laravelでの実装時に直面するであろう課題とその解決策
• アーキテクチャを維持するための取り組み
• 導入によるメリットとデメリット

「オニオンアーキテクチャって難しそう」「導入してみたけどうまくいかなかった」
という悩みを持っている方々にとって、参考になる情報をお伝えします！

驚くほど人間的な回答で世間を賑わせたChatGPT。
しかし2024年時点では工夫をせずに依頼をすると「突然英語で回答する」「架空の資料を元に回答する」など、ビックリさせられます。

本トークでは、ChatGPTに思い通りの回答をさせるためのマインドやTipsを紹介し、少しでも思い通りな回答をさせる方法についてご紹介します。

お話しすること

• ChatGPTに上手い回答をさせるためのマインド
  • ChatGPTの裏側 (LLM) を知る
  • 人間と思って接しない
• ChatGPTに変な回答をさせないためのコツ
  • Custom instructions
  • プロンプトエンジニアリング
• 業務で使う場合の注意事項
  • 学習オプトアウト
  • 機微情報のマスク

PHPUnitを支える仕組みに、イベントシステム(Observerパターン)があります
何故？
もちろん、無闇にイベントが設計されている訳ではありません
「フレームワーク(FW)の作者や利用者が感知したい・拡張したいはず」のポイントを察知して
要所要所にイベントが仕込まれている！と考えられるでしょう

イベントを知る=FWの思想に触れる手掛かりになります
普段とは少し違う視点で、PHPUnitを眺めてみましょう！

本トークで得られるもの

• PHPUnitの仕組みに対する理解
• 拡張的な使い方をするための基礎知識

話すこと

前半: 基本編〜PHPUnitの骨格が分かる〜

• テスト実行ライフサイクルの概説
• 各イベントとイベント同士の関連

後半: 実践編〜Extensionが分かる〜

• イベントシステム利用の実例
• Extensionを自作してみる

コミュニケーションは様々な場面でギャップが生じてしまいます
発された言葉「以外」の解釈コストが高くなると、受け手のイラッ・モヤッに繋がります
(何が伝わっていないの？」など)

「明瞭な部分の比率を高める」のは有効です
例えば、発言時や受信時には「事実・解釈,意見・評価,要求」の区分が助けになります
こうした工夫が、自他を尊重した態度の表現に繋がります

発表者自身が「気にしている事」「気にしすぎないために考えている事」を共有します

役に立つ事

• コミュニケーションのgood/ungoodを知ることで、仕事の「邪魔」な要素を減らす
• 言語化・形式知化された情報を手に入れることで、現場の「モヤッ」にフィードバックしやすくなる

例題

• 「肯定？否定？」「主張したいこと」がハッキリすると楽
• 「褒め」が大事なのか、あるいは必須なのか
• 「〜では？」が何故イラつかせるのか

良いコードは拡張しやすくて、そのためには適度な抽象化が必要でね──

プログラマーとしての向上を目指すと、いつでも「抽象化筋」が立ちはだかります。
が、「抽象化をできるようになるには？」と聞くと、抽象的な答えが返ってきがちで。
こいつは何だ？

私自身が「抽象に依存する、なるほど」「インターフェースって便利」と思えたきっかけの1つが、
「たぶん何かがここら辺にあって、そこに良い感じに話しかけると、きっと処理してくれるだろう」
で進む開発するスタイルに触れた事でした。

裏を返せば「話しかける相手は分からないけど、欲する事は明確である」が求められます。
抽象化思考の1つのヒントが、正にこの「過不足なく欲求を明確にし、表現する」にあるのです。

このトークでは、こうした感覚的な部分の言語化と共有を試みます。
更に、この思考とコードの記述を繋ぐ手法として「テスト駆動開発」の実践方法を紹介します。

ORMを使っている人は、それが「DBから取ってきたデータを、PHPのオブジェクトに変換して渡してくれるものだ」と知っています。
「SELECT文で取得した値からPHPの世界のインスタンスを作る所を、その目で見た事がありますか？」と問われると、如何でしょうか。

PHP製フルスタックフレームワークは、それぞれ特徴的なORMを有していることが多いです。
Active Recordか？Data Mapperか？という大局的な話から、もっと些細な「そのフレームワークっぽい癖や工夫」にも違いがあるでしょう。

このトークでは、少し踏み込んで「ORMのデータの取り方と組み立て方」を比較していきます。

題材

• doctrine/orm
• illuminate/database (Eloquent)
• cakephp/orm
• CakePHP2.xのORM 〜連想配列の使い手〜

「PHPStanを入れましょう」「静的検査、型の世界をやっていき」といった時に、
必ずしも「レベルをどうするか」「baselineがどのくらいあるか」だけに限らずとも良い訳です。

自分たちのチームやプロジェクトにとって弱みになっている部分、基準としていきたい部分について
ピンポイントでルールを入れていく道があります。
そのために、「使えるルール」が増えると良いですよね。そのまま「静的検査の語彙」になります。

さぁ！！phpstan-strict-rules が来てくれました！！！
必ずしも「全部を有効にする」っていう使い方ではないでしょう、そういうものは本体に居るはず！！

5分で全部のルールを紹介します。
紹介には、「どんなコードを指摘してくれるルールなのか？」が含まれます。

PhpStormでGitやGitHub使っていますか？

• commitしてますか？
• ブランチの操作してますか？
  • rebase, merge, switch, pullやfetchやpushも？renameも？
  • cherry-pick, revert, コミットメッセージの編集も？
  • コンフリクトの解消も？
• コードレビューも？
  • コメントを見たり解決済みにしたりリアクションをつけたり？
• ファイルや行単位での変更履歴の追跡も？
  • 該当の変更が含まれるPull Requestを開いたりも？
• 「変更リスト」の管理も？
• stashも？
• bisectも？

みたいな話をします

「ライブラリが古いせいでやりたいことが出来ない」「利用バージョンのドキュメントが既にこの世に無い・・・」そんな経験はありませんか？

古いライブラリはセキュリティリスクをもたらし、技術的負債にも繋がります。
本トークでは週次でのライブラリバージョンアップを1年以上続けている実体験をもとに、継続的バージョンアップのメリットや安全に実施するために出来る工夫、はじめ方についてお話します。

想定観客

• バージョンが古いせいで苦しんでいるかた
• ビッグバンバージョンアップでつらい思いをしたかた
• セキュリティやパフォーマンスに敏感なかた

お話しすること

• なぜライブラリをバージョンアップするべきか
• バージョンアップ時に見るべきポイント
• 安全に上げるために整えている仕組み
• 継続的バージョンアップのはじめ方と文化作り

レイヤードアーキテクチャをはじめ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャ、いわゆるクリーンアーキテクチャ、他には独立したコアレイヤーパターンやADOPなど様々なレイヤ化アーキテクチャが存在していることからわかるように、レイヤを元にアプリケーションを構造化することはとても良いアイデアです。

しかし一方でレイヤを増やしたもののあまりメリットを享受できない場面も存在します。

このセッションでは、なんのためにレイヤ化をするのか、どういった観点でレイヤが作られるのか、レイヤ化することによってアプリケーションの複雑性がどのように管理しやすくなるのかといったことを考えてみたいと思います

Laravelの魅力でもあるEloquent Model。
良くも悪くも雰囲気で書けてしまう反面、特定条件下では正しく動かなかったり、パフォーマンスの悪いコードを書いてしまう恐れがあります。

本トークではEloquent Modelを使うときにハマりがちなトラップを取り上げて、それらが「良くない理由」と「どうすれば良くなるか」をご紹介します。

想定観客

• 雰囲気でLaravelを書いている方
• 不具合が起きにくいコードを書きたい方
• パフォーマンスの良いコードを書きたい方

お話しすること

• そのコード、nullが返ってきたとき死にます
• そのコード、クエリ1,000回発行されるけど大丈夫？
• そのコード、メモリ1GB使うけど大丈夫？
• 良くある間違いを仕組みで防ぐ (Laravel IDE Helper x PHPStan)

Renovate や Dependabot などが広く使われるようになったことでライブラリバージョンアップの対応頻度が高まっている現場は多いのではないかと思います。
ライブラリは導入することによって開発コストを大きく削減できる一方、使い方によってはバージョンアップの対応コストが必要以上に高くなりますので、バージョンアップ対応にそこそこの工数が取られている人も多いのではないのでしょうか。

このセッションではバージョンアップが楽になる使い方をいくつか提示し、それぞれのメリットデメリットを整理することでライブラリとの使い方・付き合い方について考えていきたいと思います。

PHP 8.4で追加された pg_result_memory_size() は、SQL実行結果の中でも memory_get_usage() に計上されない隠れたメモリ使用量を可視化します。特に大量データ処理時のメモリ不足リスクを軽減する重要なツールです。

この関数の実際の動作を見ながら、PHPでデータベースを扱う際の注意点と解決策を検討します。

1. メモリの種類: PHPが管理するメモリとそうでないメモリ。これらはサーバの動作にどのような影響を与えるのか。
2. 実例: PHP 8.4で実際に大量データを扱い、リソースのメモリ消費量を観測。
3. 開発者へのインパクト: ライブラリやインフラストラクチャ層での考慮ポイント。リソース管理の重要性。

対象者:

• PHP開発者で、メモリ管理やデータベース接続の効率化に関心がある方
• PHP内部の実装について興味がある方

みなさんはラフティングというアウトドアスポーツをご存知でしょうか？
このトークではゴムボートで複数人が急流に挑戦するという川のアクティビティのガイド（インストラクター）という一見畑違いの業界・業種からWeb業界に転職してきた私が、
「アウトドアツアー」と「ソフトウェア開発」という一見正反対にも見える２つ産業を経験したうえで気付いた２つの業界の共通点についてお話しさせて頂きます

世の中のプロダクトは、二つに大別出来ます。 「ライブラリ・フレームワーク」と「アプリケーション・サービス」 です。

この二つには何の違いがあるのでしょうか？それは、 「インターフェースであるか、ドメインであるか」 です。

一方は多くの開発者に向けて汎用的に作られたもの、もう一方は特定のエンドユーザーに向けて専門的に作られたもの。

この二つの目線を見分けることで、様々な諸問題と正しく向き合うことが出来ます。

このトークでは、インターフェースの目線とドメインの目線、二つの目線で技術に対することで得られるメリットをご紹介します。 「技術的負債」 とは何なのか。 「技術選定」 はどうすればいいのか。 正しい目線で物事を見極めたい あなたに、是非ご覧いただきたいと考えています。

質問①：最後に誰かにほめられたのはいつですか？
質問②：最後に誰かをほめたのはいつですか？

このトークでは人間関係を円満に保つのに重要な「アクノレッジメント」と、「今日から使える」その応用テクニックについてお話します

Interfaceの設計、していますか？

適切なInterface設計はコードの再利用性を高め、保守性を高める一方
不適切な設計をしてしまうと不要な複雑性を周辺に生み出し保守性に大きな悪影響を及ぼしてしまいます

このトークでは

• Interfaceを設計するとはそもそもどういうことか？
• 良いインターフェースの条件
• インターフェース設計の先にあるもの

といった切り口に対して

• サンプルコード
• 有名な設計原則
• 書籍の引用

などを用いながら「良いInterface設計」とその効果について解説します

プログラミングの現場で、顧客の要求する仕様をクラス設計していくと、共通する機能が出てくることがあります。
そこで聞かれる
「共通する機能ってスーパークラスに実装するのと、インターフェースにするの、どっちがいいんですか？」
という疑問。
それにお答えします。
より現場にありそうな問題を取り上げて、ドメイン駆動設計の入り口まで紹介します。。

＜対象者＞
・プログラミングを始めて2，3年以上
・オブジェクト指向でプログラミングをしている
・オブジェクト指向のプログラミングを理解はできるし、自分で書いているが、うまく書けているか自信がない

成長、できていますか？
皆さんは今年どんな成長をし、来年はどんな成長を計画しているのでしょうか？

このトークでは30代半ばでの初めてHello Worldから異業種からの転職を経て、「エンジニアとしての経験年数に対してパフォーマンスが高い」と評価を受けることが多くなった現在まで、「一貫して意識してきたたった１つのこと」についてお話します。

自身のスキルに悩んでいる方、成果を出せるように成長したい方のヒントになれば幸いです

サービスを切り出す際に、既存の再利用可能な実装を活用しつつ、ヘキサゴナルアーキテクチャを導入した背景とその効果を紹介します。このトークでは、特定のレイヤーにプロセス外依存や既存コードへの参照を局所化し、依存箇所を明確に管理することで、どのように開発効率やシステムの保守性を向上させたかを具体的な事例を通して説明します。