TechTrainというエンジニア教育のサービスを3年ほどECSで雰囲気で動かしてきました・・・。
バッチの処理についてはWebサーバー全く分割されておらず、サーバー負荷が高まると落ちる可能性もあり、落ちたかもわからない。そんな状況でした。
よくある移行ではあるものの、詳細が話されることがなさそうな、ECSのTaskをECS Task Scheduleにバッチ処理を移行し、移行した際に困ったことや実は公開してなかったけど、起こっていたことをお話しします。

Laravel開発でのフロントエンドとしても使用されるVue/Reactは、コンポーネントを分割して開発する手法が多く取り入れられています。
その際、コンポーネント単位での開発を可能にするStorybookを活用し、コーディングはもちろん、Visual Regression TestやUIレビューのような、コーディングの先の運用についても活用してみませんか？

このLTでは、Storybookの開発元であるChroma SoftwareのSaaS「Chromatic」について、下記リストに挙げられる、実際に導入して得られた知見について共有します。

対象の方

• Storybookをもっと活用したい、という方
• VRT入れるの大変そうで手を出せてない、という方
• イケてるSaaSを入れたいけどセキュリティ or コストの面で自社への導入を躊躇している方

本トークを通じて、Chromaticを導入することのメリットと、導入ハードル突破の知見を共有し、Storybookをもっと活用し、フロントエンド開発をもっとスピードアップする方法を紹介します。

みなさんはこういった経験が無いでしょうか。

「PHPStanのレベル5まで対応完了！よしっ！」
「つづいて、レベル6っと、ッターン！」

Method xxx() return type has no value type specified in iterable type array.

「えぇっ！？」

このように対応レベルを上げた際、新たなエラーに直面した経験が誰しもあると思います。
特に、レベル6の型ヒントの欠落を報告での対応から厳しくなる印象です。

そんなとき、こう思った人も少なからずいるのではないでしょうか？

「PHPStanはLevel6で何を見ているのだろう」 と。

本トークでは、そういった疑問をコードリーディングを交えつつ、みなさんと一緒に解き明かしたいと思います。
PHPStanが見ている世界を知ることができれば、PHPStan(ひいては静的解析ツール)ともっと仲良くなれるはず！

■ 話すこと

話す内容としては、まずPHPStanのレベルについて概要を説明し、その後、レベル5とレベル6での解析方法の違いや、
字句解析や構文解析、評価などの基本的な概念について触れていきたいと思っています。

■ ターゲット

• PHPStanの対応(特にレベル6)で苦労したことがある人
• PHPStan(静的解析ツール)と仲良くなりたい人

私の所属する株式会社リンケージは、CTOの曽根壮大をはじめPHPコミュニティに関わりの深いエンジニア社員・業務委託が多く働いています。

私は、エンジニア社員に誘われたのをきっかけに、今年の6月に福岡で開催されたPHPカンファレンスに参加してみたのですが、あまりの楽しさと魅力に感動しました。
その結果、その後に開催された沖縄、東京の両方のカンファレンスに参加したり、Xを通してPHPerの方々と交流したりと、もはやPHPerと言っても過言ではない（！）くらいの日々を送っています。

私自身はPHPのコードを書くわけではなく、職種は事業開発出身のプロダクトマネージャーです。
傍から見ると、PHPコミュニティに入っていっても、話している内容も分からないし、うまく交流できないのではないか？と思われるかもしれません。
私がなぜ積極的にPHPのコミュニティに入り込んでいくのか、その理由を「非PHPer」「非エンジニア」という稀有な視点から熱くお伝えします！

◆主な対象者
・PHPコミュニティの魅力をPHPerの外にも広げたい方
・PHPコミュニティの魅力をより知りたい方
・知り合いをコミュニティに誘うための謳い文句がほしい方

◆主な内容
・カンファレンスへの誘い
・PHPerとの出会い
・懇親会という楽園
・Xという理想郷
・PHPerとの出会いをきっかけに変わり始めた人生

このセクションではリアルなLaravelのプロジェクトを例に、ドメインイベントを用いてどうやってコードをすっきりさせるかをナビゲートします。

テストも楽チンになるし、コードも再利用しやすくなるような、ちょっとした工夫を伝授します。

リファクタリングって難しそう？

いえいえ、このセッション後は、もう怖くないですよ。

Laravelとともに、もっとコードライフを楽しみましょう！

「このページ、なんか遅くね？」の犯人はヤス(仮名)によるヒューマンエラーと、MySQLとPHPにあるアイツでした。

皆さんは表示の遅いページがあったらまず何を疑いますか？Javascript？サーバー？そんなとき、RDBのMySQLも疑ってみましょう。ときにはクエリの数文字を変更するだけで大きくパフォーマンスが改善することがあります。

このLTでは、ページの表示を遅くするMySQLのスロークエリ、そしてその原因となる、インデックスと暗黙の型変換についてお話しします。

トークの目的
①PdM・Biz職の方：実力のあるエンジニアとの仕事で自分なりの価値をどう発揮するのかについて、ヒントになることがお伝えできればと思います！
②エンジニアの方：日々のPdMとのやり取りに活かせるような、PdMの視点・悩みをお伝えできればと思います！

トークの概要
・私は2022年4月に新卒入社し、新卒1年目、かつPdM・エンジニア等の経験なしでPdMのポジションで仕事をしていました。（CS出身）
・私が所属する株式会社リンケージでは、プロダクト価値の最大化を考えられる、課題解決能力が高い、「強い」エンジニアが集まっています。
・私はエンジニアの方々と仕事をする中で、「自分がいる意味ある？」と非常に悩んでおりました…（今も悩んでますが）
・本トークでは、「機能を考えない、Whyを考える」など、私なりに見出したPdMとしての価値、及びそこに至るプロセス・悩みをお話します！

「Nginxってどんなものなんだろう？」「Webサーバーってどうやって動くんだろう？」―こんな疑問を持つあなたに捧げる、Nginx入門者向けのLTセッションです。
このLTでは、Nginxの基本的な概念から始め、基本的な設定の読み方について紹介します。

対象者

• これからNginxを学びたい人

話すこと

• Nginxの基本的な概要
• Nginxの基本的な設定
• Nginxに設定の追加する方法

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

アジェンダ

• 1.何故キャリアのゴールを決めた方が良いのか？

  • 日々の仕事の納得感が変わる
  • 人的資産、社会的資産、知的資産の計画を立てるとゴールが見えてくる。

• 2.日本と世界におけるエンジニア市場の違い

• 3.これまでの自分のキャリア

• 4.他のエンジニアのキャリアモデルケース

• 5.どうやったら、ユニークな人材になれるのか？

• 6.自分に合ったキャリアの最適解を決める方法

• 7.実際、エンジニア出身経営者としてキャリアを歩んでみてどうだったか？

まとめ

• ゴールを決めて、自分のロールモデルを見つけよう。
• 自分がやらない事を決めるのも重要。

私は以前に海外の人に仕事を発注するオフショア開発の案件でPMを担当した事があります。その際に学んだことをお話できればと思います。
話す内容は下記になります。

• 文化の常識を疑え
  • 文化の違いにより、仕様を伝えても上手くいかない事があります。
• 仕事の進め方の常識を疑え
  • 働き方や仕事に対する考え方が違う事が多いので、注意が必要です。
• 翻訳を疑え
  • 間に通訳の人が入る場合は技術的な専門用語は上手く伝わらない可能性があるので、注意が必要です。

私はPHPカンファレンス沖縄の実行委員長を務め、カンファレンスの立ち上げを行いました。
その経験を元に地方でPHPカンファレンスを主催すると楽しいよ！という話をします。話す内容は主に下記になります。

• 開催に至った経緯
• 開催するまでのステップ
  • コアスタッフを集める
  • 日程を決める
  • 会場を決める
  • イベントサイトを作る
  • トークを募集する
  • スポンサーを募集する
    など
• 良かったこと
• 大変だったこと

テストコードを書いていますか？
テストを書いた方が良いと誰しもが思い現場でテストを整備していると思いますが、テストコードを書いた事でどんな効果が生まれるのか向き合った事はありますか。
また、エンジニア間であればテストコードへの大切さや取り組む意義について共通認識を持てている現場は多いと思いますが、
エンジニア以外の職種や事業決済者へ、テストコードの効果を理解してもらう事に苦労したことはありませんでしょうか。

今までテストコードを書かなかった現場が、主にPHPUnitによる沢山のテストコードが整備されたアプリケーションを立ち上げた時、開発・運用面・リリースの状況が変わった話や、効果を数値化した話をします。
テストコードを整備していく工数（コスト）も忘れてはなりません。その上で効果や恩恵を算出していきます。

効果測定した項目

• テストコードを書くようになるまでのチーム状況や書く過程、時間
• 多くの時間を割いていた人の手によるQAテストをテストコードでカバーできるか網羅率を算出
• テストコード整備工数とQAテスト実行工数の比較
• リリース数の変化と開発の工数変化
• テストコードによるコードと開発チームの変化

テストコードの普及がなかなかできないチームや、今後テストコード整備に取り組んでいきたい方の参考になれば幸いです。

SI業界で小規模から大規模開発まで一通り経験し、管理職もこなしてきて、経験値だけは十分に積んだと思っていた私が、SaaS業界ではその経験値を生かすことができたのでしょうか。
SaaS会社でテックリードとして転生した私が、開発視点からマネージメント視点等いろいろな気づきをお話します。

・開発フローやシステム開発の考え方は同じなようで何が違う？
・プロジェクトマネジメントではなくてプロダクトマネジメント
・SI業界の経験値は結局生かすことができたのか？

しばらくPHP界隈から離れていたPHP5上級認定技術者資格者が、久しぶりにPHPの世界に戻ってくると、浦島太郎になっていました。
浦島太郎になって改めて学びなおしたポイントは、これからPHPを学ぼうとしている人や、他の言語からPHPを触ることになった人にもきっと活かせるはず。
PHP5の時代の苦労話も織り交ぜながらお話したいと思います。

・変わっていて驚いた言語仕様の変化
・PSRって何？
・外部ライブラリの使い方
・他の言語とごっちゃになってしまったポイント

古くからあるサービスには、機能強化とともにサブシステムが増えていきました。

最初は良いけれど、
・検証サーバーは共用だったり、個人毎だったりバラバラに存在
・共用サーバーには、交代して使用する為に待ち時間が発生
・複数の人が使うので、テストデータがぐちゃぐちゃに
・サブシステムが増える度にサーバーも増えてくる
・当然、ソース修正や管理、デプロイもややこしくなる
というような問題が、だんだん見えてきました。

では、この問題の改善にチャレンジしよう！とは言いつつ、
「今まで使い慣れたエディタやリポジトリ構成、開発の流れは変えたくないよ」という声もあります。
さて、どの様に改善していったでしょうか。

・Dockerで共用サーバーを廃止して、メンバー毎の環境を整理しましょう
・コンテナ環境でも今まで通りPhpStormで開発作業ができるようにしましょう
・ユニットテストもうまく連携しましょう

※この内容は、PHPConference関西2024と同じ内容になる予定です

「良いサービス」とはなんでしょうか。
たくさんの要素があると思います。

このLTでは「接客態度」に焦点をあて、
自称クレーマーな私の実体験
・オンライン/オフライン それぞれにおける接客で 嬉しかった/嫌な気持ちになった話
・自社サービスは接客力が上がれば友達に自信を持って紹介できるのに！と感じた話
・自社サービスの接客力が上がった結果、仕事へのモチベーションが上がった話
を通じて、

「良いサービスを作る」という重要な課題に向き合う5分間を提供します。

●●●LTを聞くメリット●●●
開発をする際に、利便性や速度、正確さだけでなく「ユーザがどう感じるか」という視点を、新しく持つ、もしくは当たり前に持つことができるようになります。

●●●対象者●●●
・自社サービスのユーザとご自身との関わりが少ない方
・自社サービスをユーザとして使ったことがない方
・システムやコーディング以外についての話も聞きたい方

GitHubが提供するCI/CDサービス 「GitHub Actions」。
ドキュメントが充実していて簡単に使い始められる反面、ジョブが終わらなくてキャパを食い尽くしてしまったり、GitHub Actionsが障害中でCI/CDが出来ない、などのトラブルも耳にします。

本トークでは数多のプロジェクトでGitHub Actionsと戯れときに事故に向き合ってきた体験をもとに、GitHub Actionsを使うときにやっておくと良い設定をご紹介します。

お話しすること

• GitHub Actionsのおさらい
• タイムアウトの設定は必ず
• バージョンは明確に
• CIで出来ることはローカルでも出来る状態が理想
• 3rd-party Actionsは定期的にバージョンアップしましょう
• Environment VariablesとSecretsは正しく使い分けよう

Laravelは良くも悪くも雰囲気で書けてしまう反面、実は予期せぬ振る舞いをしていたり、パフォーマンスの悪いコードを書いてしまう恐れがあります。
本トークではLaravelでやりがちな間違いを取り上げて「これは」「こうすると良い」という話をします。

想定観客

• 雰囲気でLaravelを書いている方
• 不具合が起きにくいコードを書きたい方
• 「えっ...うちのプロダクト、遅すぎ・・・？」と感じられている方 (パフォーマンスの良いコードを書きたい方)

お話しすること

• 不具合起きちゃう編
  • Eloquent Modelの create() update() get() find() first() の返り値を正しく理解してから使いましょう
• パフォーマンス悪い編
  • レコード数多いテーブルに whereHas() や whereDoesntHas() を使うとDBが泣きます
  • そのクエリ、1,000回呼ばれてるけど大丈夫ですか？
• Laravel Wayに乗れていない編
  • クエリを書くときにとりあえずjoinを使っていたり、インスタンス生成するときにとりあえずnewしているならLaravel Wayに乗れてないかも

PHP を含む、クラスベースのオブジェクト指向プログラミング機能を持つ言語（あるいはそれ以外の言語でも）インターフェースを利用できます。
アプリケーションの実装上の設計を考えたことがある人は、インターフェースが使えると何が嬉しいのか？どんな場面で使えばよいのか？と思ったことがあるのではないでしょうか。

本トークでは、また設計の文脈で聞いたことがあるかもしれない「腐敗防止層」というワードとともにインターフェースの使い方、ひいては設計全般に通用する考え方をお話します。

想定聴講者

以下を満たす方が聴講することを想定します。

• PHP のコードは一通り書ける（フレームワーク上でも可）
• 機能追加等によって、実装上の設計を考える必要がある（考えたことがある）
• クラスベースのオブジェクト指向プログラミングにおける「継承」等の意味はわかる

みなさんはシステム障害が起きた時、どのように調査を行いますか？
根拠となるデータを元に仮説を立てて検証するというのがセオリーですが、時に必要なデータが無くて行き詰まったり、経験則や自身の勘に頼ってしまいがち、という事もあると思います。

ログ・メトリクス・トレースはシステムの状態を可視化するデータ(テレメトリーデータ)の代表格で、これらを上手く活用することにより事実に基づいて仮説・検証プロセスを回すことができます。このようにして、どれだけ複雑なシステムであっても理解しやすい状態にすること、いわゆるオブザーバビリティを高めることが近年注目されています。

OpenTelemetryはこれらのデータを収集するためのツールとして登場し、これによってオブザーバビリティを高めやすくなってきています。そして、OpenTelemetry PHPが最近GAされ、PHPにもオブザーバビリティの波がやってきました。

本セッションではまずOpenTelemetryについて紹介し、サンプルアプリケーションを通じてPHPでテレメトリーデータを収集・分析する方法を見ることで、オブザーバビリティを体感する場にできればと思っています。

想定ターゲット

オブザーバビリティ入門したい方
オブザーバビリティは知っているが、PHPでの実践方法について知りたい方