トーク

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

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

こんな方におすすめ

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

あると嬉しい知識

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

保育・教育施設向けICTサービス「CoDMON(コドモン)」は2015年のリリース以来、AWSのEC2上で動作していました。コンテナ化の機運はあったものの、巨大でレガシーなPHPアプリケーションであるため対応を先延ばしていました。
リリースサイクルの高速化や環境間の差分解消などを目的としてコンテナ化とECSへの基盤移行に踏み切り、半年ほどかけて検証などを進めてきました。

本セッションでは、EC2からECSへの移行プロジェクトがどのように進行し、どのような成果を得たのか、以下のような内容に触れてお話しします。

• EC2からECSへの移行を実施した背景
• コンテナ化に直面した主な技術的課題
• EC2環境変更、Dockerfile修正、ローカル環境への影響
• コンテナ化に伴う技術的課題の解決と具体的な成果
• 数百万ユーザーへの影響を最小限に抑えるための具体的なリリース手法

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

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

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

テストコードはプロダクトの持続可能な成長には不可欠で、私の所属する開発チームでは書くことが必須となっています。
しかし、書き方が人によって異なり、テストケースに過不足があったり、実装の仕方やレビューで悩んだりすることがありました。
そこで、テストコードの書き方をガイドラインを策定しました。現在では開発チーム全体で運用され、一定の効果を発揮しています。

本トークでは、このガイドラインの内容をもとに、テストコードを書くうえで最低限気をつけたいことについてお話します。
また、チーム全体で運用するための、策定のポイントについてもお話しする予定です。

テストコードの書き方を知りたい人はもちろん、テストコードレビューで悩んでいる人、チームで統一したコーディングルールを運用したい人にとって有益なものとなれば嬉しいです！

不確定な部分のコードを何度も修正する際、どこを変更すれば良いか迷ったり、実際に読んでみないと見積もりができない経験はありませんか？

そこで効果的なのがリファクタリングです。
私は以前、「とりあえず動く」コードを重視していましたが、設計感覚やドメイン知識が身についてくることにより、読みやすく変更に強いコードを書くことが楽しく感じるようになりました。変わらない部分と変わる部分を分離し、リファクタリングすることで、自分にも他者にも与えるポジティブな影響と、リファクタリングを楽しむためのポイントを話します。

話すこと

• リファクタリングが自分や他者に与える影響
• リファクタリングの手順やアプローチの具体例
• 意味のあるテストコードの重要性

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

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

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

現在プロダクトのインフラの選択肢は格段に広がっています。
AWSだけでも、EC2、ECS on EC2、AWS Fargate、AWS EKSがあります。
ただし、LambdaはPythonやnode.jsなどをサポートしていますが、PHPをサポートしてないということで選択肢に上がりません。
近年LambdaにWeb Adapterが登場したことで、様々な言語・フレームワークを動かすことができます。

本セッションはLambda Web Adapterで実際に動かした経験談をベースに、Lambda Web Adapterの良さや苦労話を共有できればと思います。

本セッションの対象者
・Lambda Web Adapterを聞いたことがない人
・Lambda Web Adapter or Bref + Laravelで開発話を聞きたい人
・Serverlessに興味がある人

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

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

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

「生産性改善のために、コードレビューを最優先にやる」という言説を耳にしたことがあるでしょうか。

コードレビューをしている間は当然、自分が持っているタスクの進行が止まってしまいます。
それでもコードレビューを優先した方がいいと言われるのはなぜでしょう？

その問いに対し、本トークでは「我々の仕事とは／仕事を終わらせるとは何なのか？」という観点から答えていきます。

ちなみに「すべての職場や環境においてコードレビューを最優先にすべき」という主張ではありません。
これについても「我々の仕事とは／仕事を終わらせるとは何なのか？」という観点で説明します。

「パフォーマンスチューニングは複雑で手間がかかる」と思っていませんか？
実は、コードの大改修をせずとも、仕様変更と軽微な修正だけでも大幅な改善が可能です！

本LTでは、13時間かかっていたバッチ処理を、たった一部の仕様変更で5時間に短縮した実例を紹介します。パフォーマンスチューニングは難しくない！

対象者

• 10時間以上のバッチ処理を保守している人
• パフォーマンスチューニングに苦手意識を持っている人

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 はオンプレミス版も提供しているため多種多様なお問い合わせがあります。

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

新入社員がテストコードを書けない場合、どのように教えますか？
日頃書く人は感覚的に書けますが、書いたことのない人はコツを掴むまで時間がかかってしまうものです。
皆様も経験があるのではないでしょうか？

本セッションでは、そんなテストコードのチュートリアルをpublicリポジトリとして公開・そのリポジトリの利用方法やテストコードを書く上でのテクニックをお話します。
Docker環境さえ整っていれば誰でもLaravelフレームワーク内でPHPUnitのテストを書くための問題集にチャレンジできる内容となっております。
全ての操作用のコマンドやREADMEを用意しているので、Dockerの知識がなくてもテストの実行やテスト用DBの中身を確認できます。

これを機にテストコードを書けるようになりましょう！

対象者：
・テストコードを知りたい方
・育成コストに悩んでいる方