日付計算の正確性は非常に重要であり、それには月末の計算、閏年、タイムゾーン対応など、考慮すべき事項が数多く存在します。

このトークでは、「13月が出現するバグ」や「プラン終了の1ヶ月前に送るべきメールが送信されていなかったバグ」を具体例に取り上げます。
これらのバグが生じた原因とその解法について、実際のコードを使って掘り下げます。

これらのバグは特定の日付だけで発生し、手動テストでは見つけにくいという性質があります。
そこで、Unitテストを活用することで、このような問題を早期に発見し、予防する具体的な戦略とコード例を紹介します。
バグから学ぶことの重要性と、Unitテストの利用がいかに有効であるかについてお伝えします。

■ あらすじ
今明かされるサイボウズGaroon開発チームの学生向けインターンシップの裏側。
以前開催されたのは2018年。
5年の沈黙を破り、開催されるインターンシップ。

ノウハウ乏しく、格闘するチームメンバー。
何を準備すればいいのか。
何をすれば学生は喜んでくれるのか。
最後に我々はこのインターンで何を得ることができたのか。

このトークは、そんなインターンシップの裏側で奮闘した者たちの、半年間の記録である───

■ 話すこと

• 優秀すぎる学生たちからどのように選考したのか
• インターン生の受け入れ準備で何をやったのか
• インターン生が求めるコンテンツと実際に一緒にやったこと
• インターンをやってみて得られたこと

■ こんな方向け

• インターンシップをやってみたいと思っている方
• インターンシップの進め方や内容に困っている方
• 学生との関わり方を模索している方

MySQLなどに代表されるRDBMSには、トランザクションをはじめとする排他制御が実装されています。 複数人から同時に使われうるWebアプリケーションにおいて、信頼できるデータストアとして十分な機能が備わっています。

一方で、RDBMS外のデータストアには、それと比較して柔軟な排他制御の機構を有しているとは限りません。 例えばオブジェクトストレージのAmazon S3などでは、占有ロックをとって書き込みを制限することはできません。

MySQLに備わる排他制御には、レコードやテーブル単位ではなく、任意の文字列でロックをとることのできる、ユーザレベルのロック操作(GET_LOCK関数)があります。 本セッションでは、この GET_LOCK関数を用いた排他制御と、それをオブジェクトストレージのデータ移行に適用した実例を紹介します。

開発者数が多く、MVPアプリにも高トラフィックなアプリにも採用できるPHP。
インターネットではPHPのゆるい使い方ばかりが槍玉に上がっていますが、最近のPHPは言語仕様としての型サポートも強固になってきています。

もう一歩進んで、より安全に仕様変更やリファクタリングを行うためにどういう工夫が出来るでしょうか？
本セッションでは、プロダクト開発時に堅牢性を高めるための仕組みと文化についてお話致します。

対象観客

• ビクビクしながらコードを変更しているPHPer
  -P初学者でも安全にコードを書ける環境を作りたい人

お話しすること

• 年々型安全になりつつあるPHPの言語仕様
• PHPStan (Larastan) による静的解析
• MTTRを縮めるエラートラッキングツールの活用

私が担当するLaravelアプリケーションは、DBマイグレーションの問題、テストフレームワークの不在、CI/CD環境の欠如といった荒野のような状況でした
以下の改善策を実施し、アプリケーションは徐々に成長し、品質と開発効率が向上しました

• DBマイグレーションの問題に対処、スキーマの変更やデータの整合性を改善
• PHPUnitを導入し品質保証を強化し、テストカバレッジを向上
• CI/CD環境を整備し、自動化されたテスト、デプロイのパイプラインを構築

荒野のような状況から始まるLaravelアプリケーションの成長ストーリーを通じて、「PHPUnitの導入と開発環境最適化」がアプリケーションの品質と開発効率をどのように向上させたのかをお伝えします
参加者には、類似の課題に対する解決策と効果についての具体的な知識を提供し、自身のプロジェクトに応用できる洞察を得ることができれば幸いです

みなさんSymfony Messenger使ってますか?
Symfony MessengerはSymfony Componentsのひとつで、非同期処理を扱うことができます。
このトークでは、DelayStampを使って非同期処理の実行タイミングを制御する方法や、ドキュメントには載っていない利用上の注意を実務で得た知見をもとに紹介します。

概要

ソースコードを整理する方法は数多くありますが、SLA（Single Layer of Abstraction） 原則もその一つです。この原則では、メソッドや関数内に混在するコードの抽象化レベルを整理して、異なる抽象化レベルを持つコードを分離し、同じメソッド内は同じ抽象化レベルとなるようにします。

本セッションでは、この SLA 原則の考え方をベースにして、メソッドや関数、クラス、そしてアプリケーションアーキテクチャにおいて、抽象化レベルを揃えることでより理解しやすいコードにしていく考えを解説します。

話すこと

• SLA 原則とは
• メソッド（関数）の抽象化レベルを揃える
• クラスの抽象化レベルを揃える
• アーキテクチャレイヤの抽象化レベルを揃える
• 抽象化レベルによるテスト戦略

皆さんが所属してるエンジニア組織の課題はなんでしょうか？
どの組織も何かしらの課題があるのではないかと思います。

当社ではPHPで開発された複数メディアを運営し、
エンジニアの人数も増加しながら継続的にリリースすることで順調に事業を成長させてきました。

一方で、事業が成長するにつれて「スキル獲得に漠然とした不安がある」や
「他エンジニアと交流・切磋琢磨が生まれにくい」と言った声も聞こえるようになりました。

こういった課題に対して、エンジニアリングマネージャーを中心に「技術推進委員会」という名の横断組織を作り、
メンバーで熱い議論を交わしながら課題解決の施策を考え、実施してきました。

このセッションでは、
横断組織の立ち上げからこれまでに実施してきた多くの施策や、施策を実施したことでの組織の変化について話します。

かつて登壇者の懇親会で、「いまどきテスト書こうなんて当然の話をトークしてもねぇ」みたいな話が出たことがあって、確かに！と思ったものです。
しかし、今でもテストを書いていない現場の話は聞きますし、テスト書くの大変という話も聞きます。
そこで、テストを書く意義をあえてしっかり言語化しておくことで、あらゆるエンジニアがテストを空気のように書くのが当たり前にしたいと思います。

まず、テストがあることで、本当の意味で実装が完了するということを、持続的な開発と実装のゴールの証明という観点で意義付けします。
また、その中で「カバレッジにこだわる必要はない」というある種の勘違いについても言及しておきます。
さらには、テストを書くことが、本質的にはどれも同じであり、習得コストが低いながらも効果の高いものであることを話していき、みんなでテストを書いて、エンジニアの価値を上げていきたいと思います。

チームのタスク管理について、以下のようなお悩みはありませんか？

・ タスクの優先順位がよくわからず、大事なタスクが締め切り直前なのに終わってない！
・ タスクが属人化していて、タスクは計画通りなのか、なにか問題を抱えてしまっているのかを把握するのが難しい！

私たちのチームはこの対策として、チームの開発効率と生産性を向上させるアジャイル開発手法の一つ、スクラムを始めました。
スクラムを活用することで、タスクの優先順位や進捗がチームで共有され、柔軟に見直すことが可能になりました。
また、アジャイルのマインドセットが身につき、日々のタスクへの向き合い方にも良い変化がありました。

こんな良いことづくしのスクラム、軽い気持ちで始めてみませんか？

【このLTで話すこと】
・ スクラムってなに？
・ なんでスクラムを始めたの？
・ スクラムの始め方
・ スクラムを始めたことによるチームの変化

みなさんは開発の際に用語集をつかっていますか？
人によって指す言葉が異なり混乱した経験はありませんか？
そんな悩みを、情報設計とユビキタス言語の定義を行うことで解決してみましょう！

最近、私が所属するチームで新規機能開発をすることがありました。
その際に、情報設計を行いユビキタス言語の定義を、エンジニア、デザイナー、ディレクターのみんなでやってみました。
その結果とても良い効果が得られたので、是非多くの人にそのノウハウをシェアしたいと思います！

本トークでは、実際の新規機能の開発においておこなった、情報設計やユビキタス言語の定義のやり方や進め方、それがその後のアプリケーション開発にどのように寄与したかについて話します。

IDはある要素を一意に特定するものです。まさに識別子です。
みなさんはID（の生成方法）をどのように決めていますか？
WebアプリケーションにおいてはMySQLのAUTO_INCREMENT属性やPostgreSQLのSERIAL型といったデータベースの機能を使った採番結果をIDとする方法がよく知られています。しかし、時にはデータベースによる採番では機能要件を満たせないことがあります。

IDひとつをとっても要件があり設計があります。

最近、私は2つのIDを決める場にいました。
1つはプロダクト内で使うID、もう1つはOSSのツールの中で使うIDです。
どちらも数値の採番では要件を満たせないと判断し、改めてIDの生成方法の検討をしました。
本発表ではそれぞれの事例でどのような課題があり、解決したのかを紹介します。

IDというみなさんに馴染みのある要素で、設計の楽しさを感じてください。

皆さん、コードリーディングは得意ですか？

私には苦手意識がありました…

しかし、仕事で他者が書いたコードをメンテナンスしなければなりませんし、OSSを使いこなすため、あるいは、使いやすくするためにそれを読みたくもあります。

苦手なりに工夫することで、仕事に支障なく、他者が開発したOSSを理解しPRを送ったりできるようにもなりました。

このトークではPHPで書かれたコードを理解するために行なっているプラクティスやツールを共有します。

誰向けのトーク？

• コードリーディングの経験がまだ少ない方
• PHPで書かれたコードの読み方に興味がある方
• OSSコードリーディングを通じて技術力を高めるなどしたい方

本トークの目指すところ

• コードリーディングのハードルを下げる。

2020年からモブワークという開発スタイルを継続して取り入れており、そこで感じたメリットについてお話をさせて頂きたいと思います。
またチームの熟練度の向上に伴い、モブワークの形態も進化させていった内容にも触れていきたいと思います。
実際にチームで実践していることや、それを支えているツールについても紹介したいと思います。

PHP カンファレンス福岡 2023にて「APIシナリオテストを書くべき10の理由」というセッションで登壇を行いました。
その登壇までに至る経緯を推しツールであるrunnの出会いからお話したいと思います。
個人的にはOSSへの貢献や取り組み方など、貴重な経験になったと感じており、またカンファレンス駆動開発も大変魅力的でその一部をお伝えできたらと考えています

皆さんAPIテストの自動化を行っていますか？
APIテストでは効率よくカバレッジを上げることができます。ただしE2EでのテストとなるとControllerテストとは異なりそのままではコードカバレッジを測定することが出来ません。
E2Eテスト（APIテスト、ブラウザテスト等）でバックエンドのコードカバレッジを取得する際の方法をお話させて頂きたいと思います。

世の中には止むに止まれぬ事情で古いバージョンのPHPを使用することもあります。
世の中にはコンテナという便利な技術がありますが、止むに止まれぬ事情で手元にインストールしたいときもあります。

決してそういう事情があったわけではありませんが、今回はPHP4系から8系まで手元でビルドしインストールしてみようと思います。
弊社はPHP >= 8.1 以上しか使用しないので決してそういう事情があったわけではありません。

つい手続き型の複雑なコードになってしまい、読みづらい、メンテナンス性が低いという問題が起こったことはありませんか？

一方で、デザインパターンは知っていても、いくつかのデザインパターンはPHPでは使えないと思っていませんか？
例えば、オブザーバーパターンはJavaなどの常駐することができるプログラミング言語で使うものであって、PHPでは使えないという声を聞きます。

しかし、実際の世界と向き合って、複雑な問題を解決するプログラミングにデザインパターンは有効です。それがPHPであってもです。

弊社では運送・配送業向けのシステムを作っています。コードが複雑になるという問題を実際にデザインパターンで解決してきました。

このトークではオブザーバーパターンを例にとって、それがPHPでどのように実装できるかを実際のプロダクトにも使った実装方法を紹介しながら伝えていきたいと思います

「コンピュータは0と1しか処理できない」とよく言われています。
ビット演算があったり、浮動小数点演算があったり、文字コードが16進数だったりと、PHPerのみなさんもなんとなく実感としてはあると思いますが、なぜ「0と1しか処理できない」のでしょうか。

このトークではアナログの世界・電気回路でデジタルの世界・コンピュータ処理がどの様に表現されるのか、私たちがC言語やPHPで書いたプログラムの実行結果がディスプレイやスピーカーで認識できるところまでがどの様にできているかをお話します。

ふだんの活動ではあまり気にすることのないコンピュータの基本的な仕組みの話になりますが、このトークを聞いたみなさんが今までより少し解像度の上がった目でコンピュータを楽しめることを願っています。

私はこれまでビジネスロジックとドメインロジックをほぼ同じものとして捉え、ドメインモデルが業務知識を表現できるような実装を意識していましたが、開発を進めていく中でもっと良い構造があるのではないかと思うようになりました。
そして最近では、この2つのロジックを区別しドメインモデルからビジネスロジックを追い出すことでさらに良い構造を作ることができるのでは考えています。

このトークでは、以下のトピックに関する私の考えを共有することを目標とします

• ドメインとはそもそも何なのだろうか
• ドメインモデル・ドメインロジックとはどのようなものなんだろうか
• 何をドメインロジックとして扱うべきで、何を扱わないべきなんだろうか