トーク

メンタルは崩れると業務のパフォーマンスに大きな影響を及ぼします。
比較的メンタルが弱い私が継続して業務に携わるため実践してきたセルフケアやレジリエンスと言われる回復力の鍛え方をお話します。

聞いてほしい方

基本的にどなたでもではありますが。

• 若い方（早めに身に着けておいて損はない）
• メンタル弱い自覚のある方

お話すること

• メンタルが不調になる要因
• 実践してきたセルフケア
• レジリエンスの鍛え方
• 実践したことにより得られた業務での成果

得られること

• メンタルが不調になりがちなときの対処法を学べる
• 業務でのパフォーマンスを安定させるためのセルフケアのコツ
• 落ち込んだときからの回復力（レジリエンス）の向上方法
• 長期にわたりモチベーションを保つための具体的な戦略

DDD（ドメイン駆動設計）に興味があるけど、どの本から読めばいいか迷ったことはありませんか？数多くのDDD関連書籍をすべて読むのは大変ですが、安心してください！とりあえず、手に入る本は全部読んで見ました！本トークでは、どんな人がどのDDD関連本を読めばいいのか、独断と偏見で発表します！

計算量とは、アルゴリズムが問題を解くために必要とするリソース、特に時間やメモリの量を指します。プログラムはただ動けばいいだけではありません。膨大なデータを扱う現代において、計算量はアルゴリズムのパフォーマンスを左右する重要な要素です。皆さんのコードはどれだけ効率的ですか？計算量の基本から、時間計算量や空間計算量の理解を深めることで、あなたのプログラミングスキルを次のレベルに引き上げましょう！

本トークで話す内容

• 計算量とはなにか？
• 時間計算量、空間計算量
• 実装時に意識すること

自社サービスでも、受託開発でも、機能開発の一部分だけを担当していると、全体感がわからずいつまでたっても半人前という状態になってしまいます。

本ワークショップでは「本番Webアプリケーションをデプロイして運用するという経験」を一気通貫してやったことがない方を対象に、100分間でLaravelのWebアプリケーションを作って、仕様変更をして、修正リリースを行います。

本ワークショップで得られる体験

• 本番Webアプリケーションのデプロイ経験
• CI/CDの設定
• ミニマムな運用保守体験

本ワークショップの前に必要な準備

• AWSのアカウント（本番アプリケーション動作により課金されます）
• Docker Desktop for Mac, または Windows が動作する開発用のラップトップPC
• PHPのWebアプリケーションを開発するためのツール類 IDE、ターミナル

正規表現はテキストの抽象表現です。ソフトウェアでは入力値のチェックやテキストの整形などに用いられるので、私たちプログラマにとって馴染みが深いものの一つです。

ところで、正規表現の「正規」という名前が「良い性質」という意味を持っていることをご存知でしょうか？ 実際、統計の分野では良い性質を持ち、理論の根幹となる分布に正規分布という名前が付けられています。同様に、シンプルで汎用性の高い正規表現もまた、正規という名前に相応しいといえるでしょう。

しかし、開発者に正規表現の話題を振ると 「複雑で可読性・編集容易性が低くく、辛い」 という話題になりがちです。本セッションでは、正規表現が何故複雑になり、読めなくなってしまうのかという疑問に答え、その解決方法を示します。

なお、本セッションはPHPerKaigi 2024で発表し、改良したものです．

本番運用においても、ローカルで開発を行う場合においても、Dockerなどのコンテナ技術およびAWS ECSなどの周辺サービスを利用するのはすでに一般的かと思います。
ただ、確かに便利な技術ではあるのですが、運用を続けていくうちに以下のような課題に出くわすことがあります。

・CIの実行に時間がかかる
・本番・CI・ローカル環境ごとにライブラリ・パッケージをインストールする記述が分散しておりメンテが面倒
・aptなどでバージョン固定してインストールしているパッケージが、リリース用イメージのビルドタイミングでインストール失敗しリリース時に困る

このトークでは、実際にPHPのDockerイメージを毎日自動ビルド・プッシュすることで上記のような課題を解消した事例についてお話しします。

dbt-coverageというツールをご存知ですか？

dbt-coverageとは、dbtのテストやドキュメントのカバレッジを計測するツールです。dbtはデータワークフローをSQLとYAMLで定義するソフトウェアで、dbt-coverageとはDBのテーブルに対するテストケースや、YAMLファイルにdescriptionの項目が書いてあるかを計測します。

一見するとよくあるツールに見えるのですが、コードの量が非常に少ない。実のところ、ソースコードが1000行ぐらいしかありません。この量では、とてもYAMLをASTに直し、構文解析することは不可能なように感じました。

本セッションでは、このdbt-coverageのソースコードを解説し、どのようにして短いコードで有用なカバレッジ計測ツールを実現していのかを解説します。

皆さんは自分の好みの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）や経験年数などから考えられるスケジュールの取り方の傾向
・私自身のスケジュールを立てる上で大切にしていること
・（上記を踏まえて）育成側に立たれている方に考えてみてほしいこと
をお話ししたいと思います。