DDDといっても、複数のアーキテクチャ(クリーンアーキテクチャ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャなど)があると思います。この中でどのアーキテクチャを選定するかって悩みませんか？
そんな方向けに各アーキテクチャの比較をした話をします！

話すこと

• プロジェクトの検討観点(開発規模、開発メンバーの体制、外部システムとの連携など)
• 各アーキテクチャの比較(クリーンアーキテクチャ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャなど)
• 各アーキテクチャごとの向いているプロジェクトは？

LaravelのORMであるEloquent。さっと使いたい時はとても便利ですが、使い方を誤るとパフォーマンスの低下やセキュリティホールになりかねません。
そこで本トークでは実際にコードを見ながら、EloquentはどのようにしてDBを操作しているのかを見ていきます。

話すこと
・Eloquentの内部構造

話さないこと
・Eloquentを利用した実装

仕様確認の遅れや認識のズレで開発が滞ってしまった経験はありませんか？

私は「エンジニア↔︎営業」と「営業→ユーザー」の2つのフェーズで課題に直面しました。
前者は、話し合いが後回しになっていたため、仕様確認の遅れや認識のズレが原因で開発が滞りました。
後者は、エンジニアが思い描くユーザーへのアプローチ方法が営業でうまく使ってもらえず、ユーザーへ価値がうまく届いていませんでした。また、営業にリリースした機能の価値が十分に伝わっていなかったこともありました。

そこで、以下の取り組みを行いました。
・ 何を決めたい時間かがひと目でわかる会議名をつける
・ リファインメントやランチで関係を深める
・ リリース後のアプローチ方法を営業と一緒に決める

このトークでは、エンジニアと営業が協力し、リリース後の価値を最大化するための取り組みと、その結果生まれた変化を紹介します！

最近、私は多くの人と一緒にプロポーザルを考える機会が増えています。
その中で気づいたこととしては、「話してみたい」と思っていても、それを具体的なトークにまとめるのが難しいと感じる人が多い、ということです。

そんな人たちの背中を、私はこれまで何度も押してきました。
このLTでは、その「背中の押し方」を共有します。
あなたも、身近にいる「トークをしたいと思っている人」や「トークができそうな人」の背中を押してみませんか？

話すコト

• なぜ「トーク応募」を促すのか？〜相手のため、自分のため〜
• どのように「トーク応募」を応援しているのか：問いかけと引き出し
• 受からなくても活かせる方法はたくさんある！

テストに必要なPHP環境を設定できるGitHub ActionsのアクションであるSetup PHP Actionは、PHPの各バージョンに対応しているだけでなく、さまざまな拡張モジュールやツールを活用できます。さらに、マルチプラットフォームに対応しており、LinuxだけでなくWindowsやmacOS上で手軽にテストを実行させることも可能です。このLTでは、テストやOSSのコントリビュートにも役立つ、Setup PHP Actionの使い方を紹介します。

SOLID原則・凝集性・結合度・関心の分離・DDD・クリーンアキテクチャ...
設計を考える際、学ぶべき原理や手法が多すぎて圧倒されてしまうこともありますよね。

しかし、これら設計原則は、実は私たちがよく知っている「英語の文法」にヒントが隠されているかも...?
英文法の基本的なルールに着目することで、仮に設計原則を知らなくても、シンプルで明確な設計ができるようになるかもしれません！

このトークでは、SVO・SVOCなど基礎的な英語文法がどのようにコード設計に応用できるかを具体的に解説します。
例)

• S(主語)やV(動詞)の明確化が単一責任原則の遵守に繋がること
• 「S(主語)がV(動詞)した」とクラス設計を考えることの恩恵
• コード上での形容詞・副詞の在り方

想定聴講者

• 設計詳しくないけど興味がある人
• 設計に原理・手法多くてなかなか手を出せないでいる人

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⁠対象者

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

概要

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

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

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

• tbls紹介
• 運用例紹介
• tbls新規導入と基本的な設定
• GitHub Actions活用方法

テストコードの意図をより明確にするテクニックとしてGiven-When-Then構文というものがあります。
Given-When-Then構文はどのテストフレームワークでも適用できる万能な書き方になります。
直ぐに始められて一歩先をいくテストコードを書いてみませんか？

毎日チームの朝会でアイスブレイクから始めています。
アイスブレイクってホントになんでもいいんですけど
しょうもないネタでその人の人となりが分かる瞬間、とても嬉しくなります。

しょうもないネタ集と人となりを知るポイントなどを話したいと思います

今年の3月に実施されたPHPerkaigi2024でコードゴルフ大会に参加し、とても楽しかったため、「自分の会社でも実施したい！」と思い立ち、実際に開催しました。結果は大成功で、とても楽しい時間を過ごせたので、その時の話をします。

コードゴルフの内容は、「FizzBuzz」問題や、1時間で解ける程度のの難易度のものを採用しました。言語はPHPを使用しました。

具体的には以下のような内容を話す予定です。

•コードゴルフ大会を実施するにあたって、コードゴルフができるWEBアプリをどのように作成したか
•コードゴルフ大会の雰囲気や参加者からの評判
•参加者たちの感想
•コードゴルフ大会を定期的に開催していることでの社内への影響
•コードゴルフ大会を開催した私自身の感想