トーク

皆さんは自分の好みのUIフレームワークはありますか？
このワークショップセッションでは、ReactやVue.jsに次ぐUIフレームワークとして近年人気の高まっているSvelteをハンズオンします。

前半では公式のチュートリアルも活用しながらSvelteの基本的な仕組みや記法に触れます。
後半では本セッションオリジナルの題材を用いて、LaravelとSvelteを組み合わせたより本格的な開発パターンを体験します。

こんな方におすすめ

• Svelteに興味がある
• 他のUIフレームワークを触ってみたい
• もっとスッキリUIを記述したい
• もっとアプリケーションのパフォーマンスを上げたい
• スタイルをうまく扱いたい

あると嬉しい知識

• HTML / CSS / JSの基本的な知識
• Laravelの基本的な知識
• その他HTTPなどのWeb開発全般の基本的な知識

昨年のカンファレンスで「CodeReviewerが求められること」について発表させていただきました。
その中で、Revieweeが
・気づきや学びが欲しい
・自信を持ちたい
と感じていることが明らかになりました。
またその時の発表では触れませんでしたが、Revieweeは「楽しく働きたい」とも考えていることがわかりました。

しかし、コードレビューにおいて、Reviewerが気づきや学びにつながるようなコメントをしたとしても、伝え方次第でRevieweeから楽しさや自信を奪うことがあります。
本セッションでは、Revieweeが不快にならない伝え方を探究し、PHPerエンジニアへのインタビューも交えながら、心地よいコメントの条件を考察します。
コードレビューの場が楽しくなり、組織が活発になる一助となれば幸いです。

対象者：コードレビューを行う全エンジニア（役職問わず）

皆さん社内で技術交流していますか？
私はしたいですが、できてません!!

現在は様々な会社でテックブログや勉強会、イベントの主催などで社内・社外でのエンジニア同士の技術交流が活発です。
ただし、全員が全員、活発な会社にいるとは限りません。

社内の技術交流を活発化できないかと、細々半年、本格的に活動を始めて半年が経過し、
どういう施策がダメ・よかったか、ダメだった施策の原因と対策など皆さんに共有できればと思います。

プログラマーとして生きていると、仕事をする中であるいは日々の生活の中で、ちょっとした自動化のためにスクリプトを書くことがあるでしょう。
そういったスクリプトはすぐに使い捨てるつもりだったり、あとで修正することもなかったりするかもしれません。

このとき、みなさんは「最低限の品質」をどこに置きますか？
いざ、ぱっと聞かれると返答に困るような質問かもしれません。

私のなかではある程度の基準があります。
本トークでは「ちょっとした自動化のためにパッと書いたスクリプト」をいくつかのレベルに分けて、どこまで作り込むかの観点と判断基準の一例をお見せします。

MVCモデルのフレームワークにおいて、編集ファイルが多くなり、レビューが大変になったこと、ありませんか？
どうしても編集ファイルが多くなると、変更の意図が伝わりにくく、見落としも増えがちですすよね。
スケルトンコードを活用して学びを最大化しつつ、効率的なコードレビューを実現した方法を紹介します。

お話しすること：

1. MVCモデルでの変更の複雑さと課題
2. スケルトンコードについて
3. 実際の使用結果と得られた学び

何が得られるか：

• スケルトンコード活用法
• チーム全体の開発プロセス改善のヒント

こんな人におすすめ

• 若手エンジニア
• 育成に関わる人
• コードレビューの効率化に興味がある人

似たような経験をしたことのある方にとって、少しでも参考になれば嬉しいです！

MVCモデルのフレームワークにおいて、編集ファイルが多くなり、レビューが大変になったこと、ありませんか？
どうしても編集ファイルが多くなると、変更の意図が伝わりにくく、見落としも増えがちですすよね。
スケルトンコードを活用して学びを最大化しつつ、効率的なコードレビューを実現した方法を紹介します。

お話しすること：

1. MVCモデルでの変更の複雑さと課題
2. スケルトンコードについて
3. 実際の使用結果と得られた学び

何が得られるか：

• スケルトンコード活用法
• チーム全体の開発プロセス改善のヒント

こんな人におすすめ

• 若手エンジニア
• 育成に関わる人
• コードレビューの効率化に興味がある人

似たような経験をしたことのある方にとって、少しでも参考になれば嬉しいです！

みなさんは、どのような時にパフォーマンスが上がったと感じますか？
PHPコードが綺麗に書けた時、コードやDBを最適化できた時、
上司から評価してもらった時、単に体調が絶好調の時 etc.

その中でも今回お話ししたいのは、「自分で」「今すぐに」できるパフォーマンスの上げ方として
自分に合った開発スケジュールの立て方についてお話しします。

私は今年の4月に新卒入社し、半年間の社会人経験を経て「自分の意志でスケジュールを立てることの重要性」に気付くことができました。

今回は
・社内のPHPエンジニアにアンケートを取り、性格（MBTI）や経験年数などから考えられるスケジュールの取り方の傾向
・私自身のスケジュールを立てる上で大切にしていること
・（上記を踏まえて）育成側に立たれている方に考えてみてほしいこと
をお話ししたいと思います。

求人サービス「エンゲージ」はサービス開始からLaravelのモノリスなアプリケーションとして開発が行われてきました。サービスの内製化を目指して組織が急拡大していますが、毎回の機能追加のたびに発生する大規模な影響調査、チーム間のコミュニケーションコストの増加等の理由で開発速度が低下し、ビジネスサイドと開発サイドが協調して素早くサービスの価値を最大化するという、内製開発のメリットが活かしづらい状況でした。

弊社はそのような問題に対して、イベントストーミングやドメイン駆動設計、モジュラーモノリスといった開発を選択し、開発速度の向上やオーナーシップの強化を目指して取り組んでおり、その取り組みの軌跡や失敗の経験、今後の展望についてお話しします。

普段からドメインを意識した開発に取り組まれている方、これから組織に導入していこうと考えている方をはじめ、一つの事例として参考にしていただけると幸いです。

It is the year 2024 and PHP developers are still arguing about double quotes vs single quotes.
Lets explore if that actually still matters, see why it does not, learn what happens before your code gets executed and find the answer to the question: What has the OPcache ever done for us?

PHPerの皆さんは自分が開発しているプロダクトへの愛を持っていますでしょうか？
エンジニアからプロダクトへの愛には「受託開発だから特に愛してない」から「自ら企画した自社サービスだから我が子のように愛してる」まで様々な濃度があると思います。
エンジニアが自らオーナーシップを持つために・エンジニアにオーナーシップを持ってもらうために、プロダクト愛の濃度別にできることを語りたいです。

The 1brc is "a fun exploration of how quickly 1B rows from a text file can be aggregated with Java", but let's face it, we should be able to do this in PHP too, right?
Let's see how fast we can actually aggregate 1 billion rows in PHP and learn about optimising the performance of PHP software along the way.

Ever dreamt of becoming a PHP core contributor but felt overwhelmed by the prospect of creating RFCs, maintaining extensions, or writing C code? Worry no more!
We'll discover how to make an impact on the PHP core by writing tests. Join me for an interactive session where I'll live code a test on stage, demystifying the process and equipping you with essential techniques.

弊社で開発しているサイボウズ Garoon は利用してくださるお客様のお陰で20年を超える長寿プロダクトとなりました。
当初はオンプレミス版での提供から始まりクラウド版を経て現在では多くのお客様で利用されています。
その中で私はお客様からの問い合わせに対応するバックサポートチームでエスカレーションエンジニアを行っています。
クラウドの障害対応はもちろんですが、Garoon はオンプレミス版も提供しているため多種多様なお問い合わせがあります。

このトークではエスカレーションエンジニアのご紹介と具体的な問い合わせや業務内容をお話します。

サービスは生き物のようなもので、放置すれば腐ってしまいます。
適切なメンテナンスとアップグレードが必要です。
本セッションでは、古くなったPHPフレームワーク(Laravel)を再生するための具体的な戦略を解説します。
ユニットテストの導入、Laravelアプリケーションのコンテナ化によるインフラ刷新、Laravelアプリケーション/MySQLのバージョンアップなど、数々の挑戦とそれを克服した方法を紹介します。
これにより、デプロイ頻度の向上、テストコードによる仕様の明文化、システムの安定性を向上させることができました。
実際の成功事例を通じて、参加者はPHPプロジェクトの持続的な進化を支える具体的な戦略を学ぶことができます。

年月を経たレガシーなアプリケーションの検索処理は、肥大化したロジックによりパフォーマンスが劣化しがちです。本セッションでは、実際に直面した検索遅延を、OpenSearchを活用して改善した実例をもとに、選定理由から実装の課題、実際の効果までをお話します。

ターゲット

• OpenSearch導入を検討している方
• レガシー環境でのパフォーマンス改善に悩む方

お話すること

• OpenSearchの概要
• 社内で抱えていた課題
• 選定理由
• 実装時の躓き
• 実装後の効果
• 今後の課題

何が得られるか

• OpenSearchの強みと効果
• レガシーな環境での落とし穴

PHPは、エンジニア・案件ともに豊富となり、もはや習熟していれば使いどころに困らない昨今となりました。
一方で、copilotの台頭や経営層のIT解像度の深化等により、
エンジニアへ投資する目線もまたシビアになったと言えます。

そんな中で、より魅力的なプロダクト開発や優れたチームの構築へ、私たちを連れて行ってくれるものは何でしょうか？
競合に劣らぬ価値を発揮し、プロジェクトを牽引するには、何が必要とされるでしょうか。

本LTでは、業界、業種、業態(営業→開発、医療→エンタメ等)を問わず経験した話者の観点から、
「必要だったビジネススキル」「掛け算の重要性」を主題としてご紹介します。
技術に伸び悩んだ時どうすべきか。ビジネススキルとは何か。
具体・抽象を交え時間いっぱい詰め込みます。

本LTで新たな気づき・学びをご提供し、ご清聴賜りました皆様のエンジニアライフの一助となれれば幸いです。

書き初めとは、新しい年に初めて字や絵を書くことを指します。令和6年の師走、今年最初のSymfonyを書いてみませんか？

このセッションでは、オートワイヤリングに特化し、Symfonyでのオートワイヤリングを実際に体験していただきます。Symfonyが初めての方や、他のフレームワークを利用している方にも、安心してSymfonyに触れる機会となることを目指しています。ぜひお気軽にご参加ください。

コンテンツ予定

• Symfonyのインストール
• ハローワールド
• サービスのオートワイヤリング
• インターフェースを使ったオートワイヤリング
• さまざまなオートワイヤリングの応用

バックエンド開発を担当しながらスクラムマスターを務めることになり、気づけば約1年が経過しました。この1年間、開発チームの速度を向上させるために、さまざまなアプローチを試み、試行錯誤を重ねてきました。

チーム内のコミュニケーションの改善、プロセスの見直し、ツールの導入など、いくつかの施策を実施してきましたが、特に効果が現れた方法に焦点を当ててお話しします。

本セッションでは、実際に取り組んできた施策の背景、その成果、そして今後の展望についても触れながら、皆さんと共有したいと考えています。

令和の今日。性別関係なく、メイクを楽しめる世界になりました。
その中でも、爪を塗る（ネイルする）ことは開発生産性を上げる効果があると、私は考えています。

この5分で、ネイルによって得られるメリットをご説明します。

LaravelプロジェクトにおけるL5-Swaggerの活用方法と、それによるAPI開発プロセスの効率化について深堀りします。
L5-SwaggerはLaravelでSwagger（OpenAPI）ドキュメントを自動生成するツールであり、APIの設計、開発、テスト、そしてドキュメンテーションのプロセスを大幅に改善します。