昨年のPHPerKaigiで「エラー監視とテスト体制への改善作戦」というタイトルでチームへのテストコード推進と奮闘についてトークをしました。
https://fortee.jp/phperkaigi-2022/proposal/4a7e3ded-9134-4919-955c-ec7bf4491c0d

あれから一年。テスト体制がどのように変わってきたかの話と、テストコードを高カバレッジで維持したシステム開発・運用をして得た話をします。

• 続テスト体制
• カバレッジ95%台のテストコードを整備した話
• 何をテストコードに書くかの話
• テストコードを整備しやすいシステム設計
• PHP以外のテストコードなど

【トーク対象】

• webサービス運用エンジニアの方
• テスト体制を築きたい方
• テストコードを後回しにしている方、後ろめたさを感じている方

プログラマやIT系エンジニアの実務は、(漫画やハリウッド映画でのイメージとは違い)ステークホルダーや同僚・部下との関係が欠かせず、絶え間ない学習・成長が必要で──とても「人間的な」側面が大きいものです。
何だって、人間を学ばないと！

「アドラー心理学」って言葉に聞き覚えは？仕事にどう役立つのでしょう。「認知負荷」って聞きますよね。その定義は説明できますか？
「言っている事が伝わらない」「教えても伸びない」等々、人間関係やメンタルモデルの問題は普段の仕事と密接に関わります

リーダーシップやコーチングを学ぶ中で出会った「こういう領域があるんだ」について共有します

想定対象者

• マネージャーになったばかりの人・なりそうな気配を感じている人
• 学び方や教え方について、今までと少し違う視点を獲得したい人

得られるもの・レベル

• 入門より手前の「そういうのもあるのか」を知る

メリークリスマス！
クリスマスといえば、Advent Calendarですね。
世の中には、クリスマス当日まで待ちきれなすぎて1人でカレンダーを埋めていく人も居ます。
私も、2018年に1人adventに初めて挑戦し、2021年には3枚の1人adventに挑んでみました。

このLTでは、自身の経験を通じて感じた「助かったこと」「苦しかったこと」やノウハウを共有し、「今年の12月は私もやってみようかな！！」と 道を踏み外す 奮い立つ人を1人でも増やすことを目的にお話をします。

[ネタバレ]このトークにおいて、タイトルにある「1人Advent Calendarを支える技術(よりも大事なもの) 」は「根性」です。

Web系の開発に携わっていると、「作って終わり」ではなく「ちゃんと動き続けていること」が重要になります。
そのための行為が「監視」であり、その質を保証する特性が「可観測性(Observability)」です。
私はこれまで「開発」「運用」「保守」といった区分けの無いような小規模組織で過ごした時間が長く、その経験から「アプリの人こそ、監視や可観測性を強く意識すべきだ」と確信しています。

皆さんのチームでは、「システムが動いているか気にする人/関心が薄い人」といった分断は発生していませんか？
もしくは、「監視の必要性は理解しているが、”良い監視”って？」と悩んでいる人もいるかも知れません。

このトークでは、「なぜ監視を」「なぜアプリの人が」に触れつつ「可観測性とは何か」について考えを深めていきます。

Rectorを使っているととても便利で、「フレームワークのバージョンを上げたら今までのメソッドがdeprecatedになって書き変えなきゃだぜ！！」といった場面をコマンド1発で乗り切ることが出来ます。

主要なFWやライブラリなどのマイグレーションには公式に対応していますが、自分たちのPJに適したルールは自分たちで作っていく必要があります。
「どういう風に、自動での書き換えを行わせるか・・」は知っておいて損はないはずです！
LTの中で伝えられる範囲で、Rectorを拡張するためのルールの作り方を紹介します。

みんな大好きComposer、もっと仲良くなりたいです。
仲良くなるにはどうすれば・・・やっぱりバラバラに解剖して、自分なりに構築してみることだと思います。
突き詰めれば、やっていることは「JSONを解釈して」「ネットワーク越しにファイルを落として」「ZIPを解凍して」「良い感じに展開すること」になります。
PHP自体の実行箇所(Pluginやscriptsの実行)を除けば、動かすことができるのでは・・？

Composerの一部の機能をGoで再発明してみると同時に、「Composerってそういう仕組なんですね」をシェアします！

皆さんふりかえり行ってますか？
何か物事を進めるうえでふりかえりというのはとても重要です。
自分たちが今どこにいて、どこを目指しているのか、ふりかえりを通して見つめ直すことができます。
わたしたちが行っているふりかえり術（ノウハウ・知見）を共有したいと思います。

リモートワークが当たり前になった昨今、心理的安全性の確保というのはどの組織でも重要な要素となっています。
その手法の1つに1on1というものがあります。
恐らく皆さんやられてると思います。
1on1というのは文字通り1対1の対話のため、そのやり方や手法が暗黙知になりやすいです。
社内で多くの人と1on1を行ってきましたのでノウハウや知見を共有したいと思います！

レガシーなコードと向き合っているとリファクタは避けては通れないものです。
レガシーでなくてもコード書きながら「なんかイケてないんだよな〜」となってリファクタすることも多いかと思います。

• そもそもリファクタってなんだっけ？
• リファクタってどうやればいいの？
• どうやったら上手くできるの？

このあたりのコツをお話できればと思います。

皆さんNRQL書いてますか！？
NRQLとはNew Relicで使うクエリ言語です。
監視やデータ集約にNew Relicを使っている人も多いと思います。
「目標線」「基準線」「進捗線」などのために任意の直線を引く小技を教えます。

DAPとはDebug Adapter Protocolの略で、LSP(Language Server Protocol)と同様Microsoftが作成したプロトコルです。
LSPについての解説は世の中にごまんとあるが、DAPについて触れている記事は全くといって無いのが現状です。

DAPの仕組みについてや、実際にemacsのdap-modeを用いてxdebugと繋ぎこむデモなどをしてDAPの魅力について語りたいと思います。

皆さんはPHPのビルトインウェブサーバーを使ったことはありますか?
Laravelユーザの皆さんはphp artisan serveで馴染みがあると思います。

HerokuやECSへのDeploy時にphp artisan serveでWebサーバを起動する、といったサンプルが巷に大量に転がっています。
公式サイトさえこのような記述がされているというのが現状です。

ビルトインウェブサーバーを使った時にどういう弊害がおこるのか、実体験を踏まえて話していこうと思います。

近年、PHPプロジェクトの品質を高めるためのツールとしてPHPStanのような静的解析ツールが導入されるケースが増えています。

しかしながら、PHPStanをただ単に導入しただけではバグを完全に潰すには足りません。
PHPStanに新たなルールを加えて、更に厳しくするためのPluginがphpstan-strict-rulesです。

PHPには厳密性に欠ける関数が散在します。
例えば、 in_array に第三引数を渡さないと厳密性が損われるので警告を出してくれるといったものです。

phpstan-strict-rulesを普及すれば、誰もが安心して開発できる環境が整うと信じています。

対象

• 既存のPHPStanでは満足できない身体になってしまった人
• PHPStanでは捕捉しきれないバグに遭遇したことのある人
• 型に厳しい別言語から来た人

「良いテストを作る」もしくは「より信頼できるコードのためのテストを書く」という夢があります。

例えば、「アプリケーションコードを破壊した時、テストが気付けるかを知る」「色々な入力を渡して、どういう組み合わせで変になるかを知る」なんて面白そうですよね？
その為のテスト手法があり、開発されたツールがあります。

PHPでの例を取り上げながら、それはどんなにエキサイティングか？を覗いてみましょう。
本トークには、サンプルコードや動作の様子が含まれます。聴講者は、これらの手法やツールの書き味や世界観も味わえるはずです。
もし上手く現場に導入できたなら、コードやテストに対する信頼性をガバっと上げるきっかけになるかも知れません。

トークに関連するPHPツールの例

• infection/infection
• giorgiosironi/eris

皆さんはRepositoryパターンは使われておりますか？使われている方は適切な使い方はできておりますでしょうか？自分はこれまで色々と失敗してきました。。

失敗してきた中でようやく適切な使い方が腹落ちして来ました。今回のトークでは、Repositoryパターンはどのように使えば良いのかを自分の経験をもとにお伝えしていきたいと思います。

PHP8がリリースされ、追加された関数の1つにあるmatch式。
多くの場合、大体比較されるのはswitch文ですが、if文も代替できることをご存知、または知っているでしょうか？

今回の発表ではmatch式の基本と応用、発展形や本題のif文代替ケースをご紹介しながらどれだけif文とさようならができるか挑戦します。

発表内容

• 改めてmatch式を理解する
• 基本形とよくある使い方
• 良くない使い方
• 応用な使い方
• 個人的にやる使い方
• （ひらめく限りの）本当に使う？とんでもmatch式

対象者

• ～中級者
• PHP8.0以上

「PHPは人生」とよく言います。

私は高々3年間PHPに触れただけのいわばPHPer見習いですが、大学1年から3年という人生の節目をPHPと共に過ごしてきました。

PHPでの個人開発、PHPでのアルバイト、PHPでのインターンシップ、PHPでの就活……
と大学1年にPHPと出会い、大学3年を終えようとしている現在までのPHPとの向き合い方や考え方の変化についてお話できればと考えています。

私なりの「PHPは人生」の想いをお伝えすることができれば幸いです。

エリック・エヴァンスの『ドメイン駆動設計』日本語版から11年。後発の書籍も多数出版され、各カンファレンスでDDDについて話す人も増えてました。PHPerの中にも実際にDDDで開発する（？）・DDDを実践する（？）人や組織も増えてきたと思います。
約10年前、まだPHPerでDDDを学ぶ人が少なかった頃から、私はPHPメンターズの指導を受けてDDD本を読み、楽しみながら・苦しみながらDDDを意識して開発してきました。コードサンプルを交えながら、実際にやってきた中で学んだこと、世間のDDDに対する言説に対して思うことについてお話しします。

皆さんのチームではコーディング品質はどう担保されておりますか？ガイドラインを策定されたり、人の目でチェックしてたりかと思われます。
PhpStormの機能である程度のコード品質の担保はできるものの、人力に頼ってしまっている方もいると思います。そこでツールをうまく組み合わせて人力を極力排除できる方法を共有したいと思っております。コード品質改善の足がかりになれば嬉しいです。

対象者

• PHP CS Fixer/ PHPStanを利用している人
• PhpStormを利用しており、PHP CS FixerとPHPStanのより便利な連携方法を模索している人

発表しないこと

• PhpStormの導入方法
• PHP CS Fixerのの導入方法と設定ファイルの作成方法
• PhpStanの導入方法やneonファイルの設定方法

「ユニットテスト難しいね」「上手くなれるならそのヒントをくれ」と叫んだ事はありませんか？

「xUnit Test Patterns(xUTP)」という分厚くて厳つい本があります。
「どうしたら読みやすく、メンテナンスしやすいテストを書けるのか」をまとめた本です。
これを読むと「テストに自信を持てる」ようになります。

このセッションでは、xUTP未読者に向けて、「xUTPってどんな本？」を紹介して、皆さんが「テストと仲良くなるためのヒントがこの中にあるのか？」と興味を持ってもらうきっかけを提供します。

本セッションで話すこと

• xUTPはどんな本なのか
• 各パート・各章にはどんなことが書かれているのか
• 書名にもなっている「パターン」は、どんなものが書かれているのか
  • サンプル的にいくつかのパターンの紹介
• どんな時に読むと良いか。どんな使い方をすると良さそうか