トーク

どのようなビジネス、プロダクトであろうと運用していくのに必要なのが管理画面
ただ、管理画面を作っているとこういう課題に出会ったことはないですか？

• 調査依頼が来てもどこを見ればいいかわからない
• おかしなデータが入ったことに気づけない、ログを追うのが大変
• 調査依頼からバグを再現するのが難しい

これらを1つ1つ向き合って解決し、プロダクトとビジネスの成長をさせるための管理画面の作り方を話します

話すこと

• 管理画面におけるログやデータの残し方
• 管理画面におけるアプリケーションの設計

話さないこと

• アプリケーション設計における具体的なコードの説明
• 画面のUI

PHPのmbstringのRFCを投げていても、最近ではなかなかAcceptされにくくなってきました。
それでは、代わりに何が来るのかというと、Unicodeを扱う関数であるgrapheme関数で、それを作っています。

皆さん、これからやってくるであろうUnicode大時代に向けてキャッチアップしませんか？

テストコード、書いていますか？

今日において、自動ユニットテストを整備することが開発生産性の向上に寄与することはもはや疑う余地がありません。また AI の活用により、テストコードを書くコストは従来に比べて大幅に減っています。

しかし「テストコードの書き方や導入方法がわからない」「テストコードがあるだけで満足してしまい十分にその効果を発揮されていない」「テストコードが負債化し開発の足枷になっている」などの課題に直面している方も多いのではないでしょうか。

AI がコードを書く時代になっても……いや、むしろ AI がコードを書く時代だからこそ「価値のある」ユニットテストについて一緒に考えてみませんか？

お話しすること

• AI 時代における自動ユニットテストの価値とは
• 価値のあるテストコードを書くための基本的な考え方
• よくあるアンチパターンと処方箋・テクニック

ADRとは略称で、 Architecture Decision Records の頭文字をとったものです。直訳すると アーキテクチャ決定の記録 というところでしょうか。
その名の通り、構築計画中のソフトウェアアーキテクチャの重要な側面に関してチームが取った選択について説明する文書のことを指します。

このセッションでは自身がテックリードとして所属するチームにADRを導入する→してみてどうだったか？までを一貫してお話します。具体的には以下の通りです。

• (改めて)ADRとは何か
• なぜADRが必要だったのか
• 導入までにやったこと
• 導入までに困ったこと
• 実際の運用フロー
• 導入により得られた効果