システム運用時にslack通知設定をしているシステムは多々あると思います。
私が関わっているシステムでも、日々様々な通知をslackに出しています。
しかし、slack通知が多すぎて本当に必要なものが埋もれてしまったり、@channelだらけでミュートしたくてもできないチャンネルになったりしていませんか？実は通知が届いていたのに誰も対応できなかった、なんて経験はありませんか？
そんな運用の苦労を少しでも減らす方法を、実際に運用してみて直面したケースを例にお話ししたいと思います。

■話す事
・slack通知NGパターン
・slack通知を誰が見るか
・slack以外の手段
■話さない事
・slack通知の設定方法

DRY（Don't Repeat Yourself）原則はコードの重複を減らし、保守性を高める効果的な手法ですが、適用の仕方によっては仕様変更に対応できなくなることがあります。
私が直面したのは、二つの似た処理を一つのメソッドに統合し、フラグで細かい違いを切り替えるコードでした。しかし、片方の処理を変更すると、もう片方にも影響が出てメソッドが複雑化する…これ本当にDRYなん？と思いました。

このトークでは、当時はDRYだったものが、時間とともに保守性を損ない、結果的にDRYではなくなったケースについて紹介します。
何を共通化し、何を分離すべきかを考え直し、どのようにリファクタリングを行ったかについて具体的な事例を交えてお話します！

「当時はこうでよかったが、今ここに大変更を加えたい」と感じている方や、似たような体験をした方にとって、私の対処方法が参考になれば嬉しいです！

PHPは言語仕様として様々な条件分岐を持っています。if, else, elseif, switch, 三項演算子, match, &&, ||...職業PHPエンジニアの皆さんは日々これらを使いこなして仕事をしていることと思います。では、ユーザー要求や要件の中に、あるいは要求以前のビジネスの中に、仕様書やフローチャートに表される前の条件分岐の形を見出す力はどうでしょうか？自信ありますか？
このトークでは、PHPの様々な条件分岐を概観した上で、日常で人間が行っている様々なビジネス上の判断をPHPの条件分岐に落とし込む考え方についてお話しします。
様々な条件分岐が「見える」生活をしてみませんか？

This session bridges the gap between PHP and JavaScript by comparing modern features like arrow functions, classes, and destructuring in both languages. Attendees will see how PHP has evolved to include features familiar to JavaScript developers, simplifying cross-language development.

This talk focuses on leveraging modern PHP features like arrow functions, typed properties, and named arguments to write robust, clean, and maintainable code. It offers best practices for structuring and organizing code and includes examples of bad code, showing how to resolve these issues with specific PHP features.

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

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

• オニオンアーキテクチャを採用した理由
• 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 などが広く使われるようになったことでライブラリバージョンアップの対応頻度が高まっている現場は多いのではないかと思います。
ライブラリは導入することによって開発コストを大きく削減できる一方、使い方によってはバージョンアップの対応コストが必要以上に高くなりますので、バージョンアップ対応にそこそこの工数が取られている人も多いのではないのでしょうか。

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

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

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

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

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

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

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

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

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