SaaSでは複数顧客のデータを同じApp、データベースサーバーで扱う設計(マルチテナント)をよく用います。
リソースの運用効率がよく管理も楽ですが、他顧客のデータにアクセス出来てしまうリスクを抱えています。

これでは攻撃が怖くて夜しか眠れない…情報流出のニュースを見るたび不安で寿司しか喉を通らない…恐怖を和らげるために毎日飲みに行ってしまう…
安心して遠くのカンファレンスに行くこともできません。

この対策として、顧客別にデータベース スキーマ(MySQLでの"データベース")を分け、DBユーザも分離する方法を紹介します。
DBユーザ権限の制限により、ロジックミスがあっても、仮にSQLインジェクションが通っても、絶対に他顧客データにはアクセスできない設計です。

またCakePHPのORMでこの運用を自動化し、ロジック側で意識せず運用する方法も紹介します。

クリーンアーキテクチャの同心円で、一番外側にあるデータベース。ドメインのコードはデータベースに依存させないように書きましょうと言われがちです。しかし、果たしてデータベースは本当に常にドメインの外側に置くべきなのでしょうか？
リンケージではLaravelとDoctrineORMを組み合わせてドメインのコードとフレームワークの距離を保ちつつ開発していますが、ドメインとデータベースとの距離については議論がありました。
Doctrineという技術選定、ドメインのコードからORMへの依存を許す決断をした根拠についてお話します。

単位時間あたりの充実度，高めたいですよね．
これだけ情報過多の世界になって，いいブログやいいスライドもたくさん出てきました．
　
「いいブログやいいスライド以外を掴んだら時間が無駄」
「センスのある人の発信を追いかけるだけで十分」
そうお思いの方はいらっしゃいませんか？
　
あるいは，
「チームメンバーにも自主的に情報収集してほしいけど，なかなか行動を起こしてもらえない」
と，嘆かれている方はいらっしゃいませんか？
　
これらの思い込み，悩みに，永遠の別れを告げましょう．
私が取り組むインプット活動である「ブログを読む会」を紹介します．
　
inspired by https://iidasaketen.thebase.in/items/8376621
参考情報 : https://note.com/tomio2480/n/nf909bb77b4b7

1年前の私は、チーム開発や複雑なシステムの開発経験がほとんどありませんでした。
しかし、試行錯誤しながら色々な「道具」を身につけていき、中途入社1年足らずで複雑な業務システムのリファクタリングのリーダーを任されるまでになりました。

私が開発で使っている「道具」は最新のパッケージばかりではなく、ごく普通のアナログなものも数多くあります。
このトークでは以下を実現するために、私が普段使っている七つ道具を紹介します。

・思考の整理にはこれ -> 〇と〇〇
・見落としをなくせ -> 〇〇〇〇〇〇〇
・複雑なパターンを攻略 -> 〇〇〇〇〇〇〇〇〇〇
・「わかっている」が落とし穴 -> PHP〇〇〇〇〇
・論より証拠を提示せよ -> PHP〇〇〇〇〇〇〇〇
・縦横無尽に検索 -> 〇〇〇〇
・退屈なことは… -> 〇〇〇〇

対象者
仕事でコードを書き始めて1~3年くらいのエンジニア

WEB開発において、コンテンツ管理機能の追加は一般的な要件です。
ブログ機能の追加を例に挙げてみましょう。
従来の開発プロセスでは、データベース設計、投稿機能、画像アップロード機能などの実装に多大な手間とコストが必要になります。
このプロセスは開発者にとって負担が大きく、プロジェクトの進行を遅らせる原因にもなります。

本トークではLaravelとヘッドレスCMSのmicroCMSを組み合わせることで、この問題を効率的に解決する方法をご紹介します。
LaravelアプリケーションとmicroCMSの連携方法、APIを活用したコンテンツの取得や表示の方法をコードスニペットを交えて解説します。

本トークの内容を実践すれば、開発の自由度を高めつつコンテンツ管理の手間を減らすことができます。
あなたはより効率的に、そして柔軟にプロジェクトを進められるでしょう。

私はこれまで幅広いキャリアを歩んできました。経歴としてはSES企業/Web系自社開発の上場企業/フリーランスエンジニア/起業/Web系受託開発企業/スタートアップ企業/プログラミングスクール講師/地方移住などです。
その中で得られた経験などを元にエンジニアとしてどのような選択肢があるのか？というお話をできればと思っています。

アジェンダ

1.何故キャリアのゴールを決めた方が良いのか？
日々の仕事の納得感が変わる
人的資産、社会的資産、知的資産の計画を立てるとゴールが見えてくる。
2.日本と世界におけるエンジニア市場の違い
3.これまでの自分のキャリア
4.他のエンジニアのキャリアモデルケース
5.どうやったら、ユニークな人材になれるのか？
6.自分に合ったキャリアの最適解を決める方法
7.実際、エンジニア出身経営者としてキャリアを歩んでみてどうだったか？

Visual Regression Test（VRT）とは変更前と変更後のコードで対象画面のスナップショットを比較することで、発生したUIの差分を検知し、見た目のリグレッションが発生していないかを検証するフロントエンドのテスト手法の一種です。

一方で、VRTは強力なリグレッションテストツールでありながら、Flakyで壊れやすく、継続的な実行が難しい側面もあります。

本トークでは、チーム開発でVRTを行う過程で問題となることや、継続的にVRTを運用する方法について実体験をもとにご紹介いたします。

新卒2年目(発表時)のPHPerがPHPのあるあるを時間の許す限り言い尽くします！

私はおよそ9年弱同じ会社に勤め続けた後、今年の4月1日に新しい職場に転職します。

これまでも私は前の職場で3つのチームで働いてきて、異動するたびに自分なりに素早いキャッチアップを意識して様々なことをやってきました。逆に自分のチームに新しいメンバーを受け入れる際にも工夫していたことがいくつかあります。

PHPカンファレンス福岡2024当日は、私が新しい職場に転職してほぼ3ヶ月経過しているので、実際どういった工夫を実施したのか・周りのメンバーからどういう支援を受けたのかを発表いたします。上手くいったことも、逆にそれほど上手くいかなかったこともあるかもしれません。

このトークは今後社会人になる予定の人、初めて社内で異動をする人、初めて転職することになる人にとって有意義なトークになることを目指します。

みなさんは OSS に contribute した経験はありますか?
すでに contributor の方もいれば、興味はあるけれど、一歩を踏み出す勇気がまだ出せていない方もいると思います。

かくいう私も、 OSS への contribute に興味はありつつも、その一歩が踏み出せずにいる一人でした。
そんな自分が、とあるきっかけで OSS に Pull Request を送り、 contributor になりました。

本トークでは、 OSS の contribute を躊躇していた私が OSS contributor への第一歩を踏み出せたきっかけについてお話しします。
実際に contributor になった経緯を余すことなくお話しします。

このトークを聞いたら、きっと OSS やコミュニティがもっと好きになりますよ!
(なぜ コミュニティ も? それはトークでのお楽しみ!)

みなさんは GraphQL を利用したことはありますか?
GraphQL の利点として、クライアントが必要とするデータを API に 過不足なく伝達して取得できる という、 従来の REST API では実現が難しい機能 を実現できます。

GraphQL は さまざまな言語やフレームワークでサポート されており、 PHP でも利用できます。
さらに、 Laravel では、簡易的な API サーバーであれば容易に実装が可能です。

本トークでは、 GraphQL の基礎と、 Laravel で GraphQL サーバーを実装する方法を紹介します。
また、実際に Laravel で GraphQL を利用した事例についてもお話しします。

一緒に GraphQL の基礎を学んで、 GraphQL の便利さを体感してみませんか?

WEBアプリケーションを安定的に運用する上で、多くの考慮が必要です。
私たちのチームは、PHPアプリケーションをAWS上で運用しており、コスト削減とセキュリティ向上の
課題に直面していました。

本セッションでは、AWS認定資格を取得する過程で得た知識を生かして、
これらの課題解決に向けての取り組みを、主に下記の内容について具体的にお話します。

・コスト最適化のために検討したサービスや設定の変更点
・セキュリティを強化するための機能やベストプラクティス

本セッションを通じて、明日から実践できる費用対効果の高いソリューションを見つけることができます。
インフラに関わる機会が少ない方でも運用への興味と意識が高まることでしょう。

私の職種はPdMであり、PHPerでもエンジニア経験者でもありませんが、2023年のPHPカンファレンス福岡を皮切りに、計5回（予定）のPHPのカンファレンスに参加してきました。
知識も経験もない私がカンファレンスを楽しめているのは、間違いなく懇親会を楽しめているからだと思ってます。

これまで、懇親会を楽しむためのインプットとアウトプットを繰り返し、どのような考え方でどのような行動を取ると最高に楽しめるかが分かってきました。

PHP領域において圧倒的ハンデを背負う私が実践するノウハウは、参加経験の少ない方がカンファレンスを身近に感じるきっかけになるのではないかと思ってます。
懇親会前のLTで、ぜひお話させてください！

◆主な内容
・懇親会ってどんな感じ？
・懇親会を楽しむためのコツ（思考編）
・懇親会を楽しむためのコツ（行動編）
・懇親会だけじゃない！より楽しむためのノウハウ

みなさんモック大好きですよね？
外部依存から隔離してテストの実行を容易にする便利なものですもんね。

しかし、かの名著、オブジェクト指向設計実践ガイドでは、こう言っています。
モックを使用したテストは「夢の世界に生きる」状態を作る可能性があると。

この「夢の世界に生きる」という表現は、モック(スタブ)を使って現実から隔離された環境でテストを行う「理想の世界」を指すメタファーです。
現実世界とは異なる世界を作ってしまえるが故の脆さも表しています。
具体的には、モックの使用で実コードとテスト間のふるまい(インターフェイス)に乖離が生じ、テストの信頼性が落ちる可能性などが挙げられています。

では、モックの使用を避けるべきかというと、そうではないと思っています。
重要なのは、モックとの「上手な付き合い方」を見つけることです。

一緒に夢の世界でモックとの上手な付き合い方を見つけてみませんか？

このセッションでは、「何か」を求めカンファレンスや技術イベントに参加して次のアクションに繋げたいと思っている方に「今からできるアクション」をお伝えします。

私は、技術同人誌即売会にスタッフ参加したら、パソコン雑誌に記事を投稿できること知り、記事を投稿したら、掲載していただけました。
参加している最中は、実際に「執筆する」というアクションまで想像できていませんでした。
しかし、参加したことで、「なんとなく執筆してみたい」が「このような記事を執筆したい！」に変化し、次のアクションに繋げることができました。

皆さんも何かを求めてカンファレンスに参加していませんか？その何かに出会うために、PHPカンファレンス福岡2024からできるアクションをお伝えします。

話すこと

私の

• カンファレンスから次に繋げる方法
• カンファレンス開催中の動き方
• カンファレンスが終わった後の動き方

AWS Lambdaは、公式ランタイムにPHP対応はありません。
ですが、Matthieu Napoliさんが開発しているBref(ブレフ)を使うことで、PHPを使えるようになります。

このプロポーザルをご覧になっている、カンファレンス支援システムであるfortee(フォルテ)。
PHPerKaigiやiOSDCを主宰している長谷川さん(@tomzoh)が開発しはじめたCakePHPベースのアプリケーションです。
様々な機能があり、数年の歴史が積み重なったアプリケーションであるforteeを、AWS Lambdaと他AWSサービスと組み合わせてデプロイしてみます。

成功するのか？すんなりデプロイできるのか？
失敗するのか？AWS Lambda用に変更対応が必要なのか？
費用はどの程度になるのか？
forteeデプロイで得られたAWS Lambda/Brefの知見をご紹介します。

フルスタックウェブフレームワークであるPHP(独自見解)には、他言語とはことなり、Version 4からはセッションが標準拡張として搭載されています(拡張なんですよ、知ってました？)。便利ですよね、$_SESSION。

しかしPHPのセッションは様々な罠も多く、Easyではありますが、Simpleではない、安易に頼るとしんどい時もあります(個人の主観)。

今回、PHPのセッションのPros/Cons、アンチパターン、避けてみる話やセッションのマイグレーションの話をできればと思います。

エンジニア同士の繋がりを作る上でコミュニティの存在は重要です。
私が異業種からIT業界への転職を目指した際に、業界内の知り合いが少なく孤独感を感じていました。

そのような背景からエンジニアを目指す人達が一緒に勉強したり、情報共有できる場を作りたいと感じるようになり、
プログラミング学習コミュニティを立ち上げて運営しておりました。

活動内容は、LT会や交流会、勉強会を開催するなど多岐に渡ります。

コミュニティ運営をすることで学習に対するモチベーションを保てたり、繋がりの輪が広がるなど良い面もありましたが課題も多くありました。
本トークではコミュニティ立ち上げから閉じるまでに経験したことや、具体的な事例を運営者目線でシェアすることで、
コミュニティ運営の魅力やメリット、デメリットをお伝えします。

コミュニティ運営に興味のある方や、運営していて課題を感じている方にお届けしたいお話です。

普段何気なく使っているであろうORM。Laravelを使っていると、勝手にEloquentという便利なものが一緒についてきますよね。

新卒・中途採用でも初心者のPHPerの方と話していると、「生のSQLは全く書いたことがなくて…ORMでならデータ操作を表現できます」という方も少なくありません。
逆にずっと生のSQLを書いてきた人からは「生クエリならすぐ書けるのに、ORM使ってJoinやサブクエリ書くのめちゃめんどい」という声をよく聞きます。

では…

自由自在にORMがかければ生のSQLを知っておく必要はないでしょうか？
あるいは、生のクエリを自由自在にかければORMは必要ないでしょうか？

といわれると、そんなことはないですよね。
このセッションでは上記の疑問に触れつつ、「なんとなくORMを使っている」人に向けて「なぜORMを使うのか？」についてお話ししたいと思います。

エンジニア組織において、「いかに組織全体で学びの機会を増やすか？」というのは至上命題かと思います。
私はこれまで本業では3社を経験し、その3社ではいずれも「組織の学び盛んにすること」を掲げていましたが、
1,2社目では主体的に勉強会の枠組み作りに関わっていましたがうまくいかず、3社目でようやく組織全体に学びの意識が浸透している状況に遭遇しました。

そこで本セッションでは、私の失敗経験と学びがうまく行っている組織を対比しながら、

• 私の失敗談
• "うまくいっている"社内勉強会とはどういう状態なのか？
• 失敗談から学んだ、社内勉強会づくりにあたってのアンチパターン
• 社内勉強会を定着させるために必要な土壌とは？

といった内容をお話しできればと思います。