トーク

Composerはとても便利で、生活必需品ですね！！
ただし、狭い意味での composer install を考えると、 「composer.lockを読み取って」「ファイルをDL・解凍・規定のパスに配置する」というだけです。

もし、Composerの中身(実装)を読んで、仕組みを理解して、気持ちに寄り添う事ができれば・・・
必ずしも「PHPプログラム」ではなくても良いかも知れない。PHPの世界を飛び出して、Composerを実現する！！！
そんな夢を、私は見ました。

本LTでは、「composer installのためのツールを、Goで作ってワンバイナリで動かせるようにする」をテーマに

• どのような実装になるのか
• (PHPと比べて)実装の差異はどのように現れてくるか / PHPの弱点を補ったり、Goらしい味を出せるのか
• もしかしたら何かの実用性もあるのか

と言った点に触れてお話をします。

現代のPHPには、既にComposerは欠かせないものになりましたね！
これ1つで、様々な機能やソリューションをもたらしてくれるツールです。

そんな便利なComposer、もっと仲良くなりたいことでしょう。
読んで、把握して、自ら作ってみるのはいかがでしょうか。
PHP自体の機能を利用しないと行けない機能(例えばPHP自体の実行を伴うCommandのフックなど)は難しくても、
「composer.lockを読み込んで(なぜなら純粋なJSONだから！)」「vendorディレクトリにソースを展開する(それってファイルのDLと展開ですよね！)」といった処理くらいならできそうに思いませんか。

やってみましょう！

やること

• composer install の実行する単機能ツールをGoで作成し、その解説
  • composer.lock が事前に生成されている事を前提

本セッションで得られるかも知れないこと

• 一歩引いて考えた「Composerの仕事は何で、どういう仕組みか」という理解
• 「非PHP実行環境で、ワンバイナリでcomposer installが実行可能になったら何か便利なことある？」という考察

様々なロジックが密に結合したモノリシックなアプリケーションは開発速度を遅くする一方で、マイクロサービスアーキテクチャはサービス間のコミュニケーションやトランザクションなどといった別の課題があります。
モジュラーモノリスは、モノリシックなアプリケーションの中にドメイン境界を引いて疎結合な状態をつくる、モノリスとマイクロサービスの中間的なアーキテクチャです。

このトークでは、モジュラーモノリスをLaravelアプリケーションに適用する方法を具体例を用いながら紹介します。Laravelを例にしていますが、他のフレームワークにも適用できる内容です。

Laracon Onlineで話した内容に少し付け加えて日本語で話します。
https://www.youtube.com/watch?v=0Rq-yHAwYjQ&t=4057s

トーク内容

• モノリスとマイクロサービスのメリット・デメリット
• モジュラーモノリスとは
• Laravelアプリケーションのディレクトリ構造をドメインごとにモジュール化
• ドメイン間のコミュニケーション
• モジュラーモノリスなアプリケーションのテスト
• ドメイン境界を超えたコードの自動検知

One of the reasons that PHP Developers give for not doing TDD (Test-Driven Development) is that it takes a lot of time to learn. This is a fair reason: doing TDD with PHPUnit can be quite difficult, and doing things like mocking / using doubles can get very complex if you are using a Web Application Framework such as Symfony or Laravel.

Enter PEST: a new Open Source testing framework with its own code style. Built by one of the Laravel core team, it takes much of its structure from the Jest JavaScript testing framework. Its focus is on human-readable, simple yet powerful code to make testing a delight.

In this session, we'll learn:

• How PEST is structured
• How to write tests for common scenarios
• How to use PEST on your existing code

PHP_CodeSniffer(phpcs)は、「コードの書き方に規則を持たせようよ！！」を支援してくれるツールです。
予め定義したルールセットに従って、開発時のローカル環境やCI環境上で「ルールに沿っていないコード」を検出し、指摘してくれます。
また、同梱のphpcbfコマンドを利用することで、簡単な整形を機械的に行うことも可能です。

そんなphpcs、利用中の方も多いと思います。
では、中身はどうなっているのでしょう。どうやってPHPで実現しているのか・・気になりませんか？
「なぜphpcs/phpcbfは動くのか」を実際のコードから紐解いて見ます。

話すこと

• phpcsの基本的なライフサイクルや概念
• phpcsの中身(コード、実装)
  • 例えば「Sniff」とは何であり、どのように読み込まれて利用されるのか
• phpcbfの基本的なライフサイクルや概念、処理の流れ

得られるかも知れないこと

• phpcsを”理解”することによって、独自のsniffやrulesetを扱いやすくなるかも知れません

WebアプリケーションでUIをリッチにしていくには欠かせない、JavaScript。
しかし、バックエンドを作りながらフロントの動きを作っていくのは意外と骨が折れます。

なるべくJavaScriptを書かずにUIをリッチに作っていくためにSymfonyには『Symfony UX』があります。
生まれて約1.5年のSymfony UXですが、大幅に改善・進化しました。
そんなSymfony UXの魅力や使い方について紹介していきたいと思います。

話すこと

• Symfony UXとStimulus
• Symfony UXの各コンポーネント
• 実際の使い方

話さないこと

• Symfonyの基本的な使い方
• オートワイヤリングの詳しい説明

フラットなPHPの書き方はわかった、では次はフレームワークへ…というとき、どんな基準でフレームワークを選んでいますか？なぜそのフレームワークを使ってアプリケーションを書くと良いのか、理解できていますか？堅牢でメンテナブルなアプリケーションを作るとき、なぜフラットなPHPでは難しいのでしょうか？
入門書や動画講座でPHPの基本文法を学んだあと、盲目的に次のステップとしてフレームワークを学習するのではなく、必要性を実感した上でフレームワークを学習してほしい、と私は常々考えています。
このトークではフラットなペラ1枚のPHPスクリプトから出発して、オブジェクト指向で自動テストのできるPHPアプリケーションへ、そして更にフレームワークを使ったアプリケーションになるまで、コードと考え方をお話しします。

◆含まれるもの

• PHPのオブジェクト指向の用語と書き方
• ありふれたスクリプトの中に埋め込まれた「仕事」の発見と整理の考え方
• PHPUnitを使った自動テストの基本
• Symfonyフレームワークを使ってHTTPリクエストを受け取ってHTTPレスポンスを返すまで

◆含まないもの

• データベース操作
• テーブル設計
• Laravelフレームワークの使い方

Githubが提供しているDependabotをみなさんは活用していますか？
Dependabotは大きく分けて3つのサービスを提供しています。

• Dependabotアラート
• Dependabotセキュリティアップデート
• Dependabotバージョンアップデート

私が所属しているM&Aクラウドではもともとアラートとセキュリティアップデートのサービスを利用し、最低限の保守としてPHPやJavaScriptの依存ライブラリをメンテナンスしていました。
最近になりバージョンアップデートを利用して常に最新のライブラリに依存するように運用を始めたところです。
このLTではこのサービスの概要と弊社の運用を紹介し、ライブラリの依存関係を常に最新に保つための方法を紹介します。

■ 発表内容
チーム開発に効果的なアジャイルのプラクティスとその実践例を紹介します。

■ ストーリー
「ゴールデンウィーク明けまでにこの機能を作ってほしい」と社内向けの新規機能の開発を任されたとあるチーム。このチームは4月頭に組成されたばかりであり、開発する機能はビジネスの成長ドライバーになることを期待されている。期間は1ヶ月しかない。ただし、その1ヶ月に根拠はない。

チームの構成はプロダクトオーナー1名、エンジニアマネージャー1名、エンジニア6名。不確実性に対処しつつ円滑にリリースを行うべく、アジャイルのプラクティスを実践して開発に立ち向かっている（6月上旬にリリース予定日が立てられて、6月下旬にその日通りにリリースできた）。確かに当初の予定よりは遅れている。

しかし、チームのエンジニアの誰一人として疲弊しきっていない。むしろ、組織の中で偉いAさんは「遅れていても、着実に進んでいることがわかる上に、遅れの理由が納得できるので安心感がある」と言い、スクラムマスターBさんは「このチームではスクラムがうまく回っている。もしそうでなければ、リリースはさらに1ヶ月以上遅れていただろう」と述べている。

なぜそれが可能なのか。何がうまくいっているのか。チームで実践したアジャイルのプラクティスとその実践例を紹介します。

■ 発表内で登場するキーワード（予定）

• DevOps → セキュリティのシフトレフト、トランクベース開発、同期レビュー、継続的なデリバリ
• XP → 全員同席、ペア・モブプログラミング、TDD、インクリメンタルな設計、コードの共有、本物の顧客参加
• スクラム → プロダクトバックログ、プロダクトレビュー
• 実装 → クリーンアーキテクチャ、戦術的DDD
• その他 → 荒ぶる四天王（時間・スコープ・予算・品質）、リファクタリング、イテレーション、フィードバックサイクル

テスト書いてますか？
テストを書く理由と実際のテストコードを紹介する実践編に分け、TDD を3年間実践してきた経験に基づいてお話しします。

テストを書いたことのない方が、テストを書いてみたいと思ってもらえることを目指します。
サンプルコードは PHP + PHPUnit ですが、他言語でも通用する考え方を紹介します。

■ 概要
・なぜテストコードを書くのか
・レガシーコードとは、テストのないコード
・テストはコストが安いフィードバックループである

■ 実践編
・テストケースは日本語で書こう
・いろんな assertion を知ろう
・arrange / act / assertion のテストコード実装パターン
・set up / tear down を使って前処理/後処理をする
・dataProvider でテストをまとめる（ただし早すぎる抽象化に気をつけよう）

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

イントロ

リーダー未経験の私は、現職で働き始めてからの2年間で、初めてProject Leader→Tech Lead→Engineering Managerと任命されることになりました。
「影響力を発揮してね！」とか「リーダーシップを持ってね！」などと言われます。
・・が、一体どうしたら「それらをよく発揮してくれたね！！」と認められるようになるのでしょうか。
自分で道を切り拓いてこそリーダーだ！！という考え方も分かりますが…

マネジメント系のキャリアを目指す人、あるいは運命的にそれに任命された人、今の環境に何らかの物足りなさを感じる人、etc.。
私以外にも、色々なところに「じゃあリーダーシップって何？」に関心を持ったりモヤモヤしている人はいるかと思います。

概要

このセッションでは、
アジャイル(主にScrumやXP)ついて勉強したり、メンバーとの1on1で聞いた声や反響、認定アジャイルリーダーシップ研修Ⅰ(CAL-1)で学んだことを踏まえながら
「(プロダクトの開発組織における)リーダーシップってなんだろう、何を求められているんだろう？」についての自分なりの考えを共有していきます。
「リーダーシップについて駆け出した/駆け出そうとしている人」に向けてのヒントになればと思います。
それらのテーマに向き合うことで、日常の仕事の中においての「自分が何を目指すか」「チームの進化にどう繋ぎ込むか」を探っていきましょう。

想定する聞き手

• Engineering ManagerやLead/Leaderとして駆け出した人
• そうしたポジションをこれから目指したいと考えている人
• 職場で「リーダーシップ」を求められるけど、それが言語化されていなくてモヤモヤする人

参考にする書籍の例(一部)

• みんなでアジャイル
• エラスティックリーダーシップ
• LEADING BEYOND CHANGE
• The Agile Leader
• ポジティブ・チェンジ

※ このトークはリモート登壇です

繝｢繧ｸ繝舌こ

文字化けとは↑のようなことを差しているように思われますが、
文字化けに悩まされた時代の文字化けはこんなものではなかったように思います。

例えば、Shift_JISではたくさんの亜種が生まれていました。
①は機種依存文字だから使ってはいけないよとか言われました。
メールをJIS(ISO-2022-JP)で送信する際の関数はmb_send_mailの前にmb_languageを設定するのだっけ？

閑話休題。
PHP 8.1から、major overhaul of mbstringという、mbstring拡張の大規模な改修が反映されるようになってきました。
そのためか、後方互換性の失われた動作をする文字を見つけてIssueにて報告しました。
確かに仕様通りに実装するとそうだったけども、当時の実装はそんなに厳密じゃなかったがゆえの後方互換性の破壊だったようです。こういうことこそが文字化けな気がしてきますね。

このトークでは、上記のようなことがあったことから、文字コードがどのように扱われていたのかをおさらいし、きちんと記録に残しておきたいです。

古くはフルスタックエンジニアと呼ばれた人たちは、物理サーバーへのOS/各種ミドルウェアのインストールからネットワーク設定をし、さらにその上で動くアプリケーションを開発してきました。幾年が経ち、我々の前にはクラウドインフラが立ちはだかります。物理的な経験があるエンジニアにとっては、良くも悪くも抽象化されたインフラをどうにか乗りこなしているようです。
翻って、業界に入ったときからクラウドがある世代の PHPer にとっては、インフラは無限に知ることがある領域になってしまっているように感じます。
アプリケーションを構築するようにインフラをコードで表現できる AWS CDK を使って、インフラをより身近に感じて貰えるような話をしたいと思います。
※ AWS CDK なので AWS のみです
※ TypeScript で書くので PHP は登場しません
※ ベストプラクティスの話はしません、あくまで入門です

クラスに名前をつけるとき、どんな名前をつけていますか？どんな根拠で名前をつけていますか？
Webアプリケーションの寿命が長くなったとき、年月が経っても、メンバーが入れ替わっても、「このクラスはどんな働きをしているか」「この処理はどのクラスにあるか」を見つけやすい状態を保つためには、クラスの名付けはとても重要です。
より良いクラスの名付けをするために役立つ、原則と考え方をお話しします。

ここ5年ほど、自分の部署の勉強会を企画・運営してきました。
5年間同じスタイルで続けるのではなく、いろいろ変革してきました。
最初はスピーカー集めで大変だった勉強会、、ですが、
直近で開いた勉強会はめちゃくちゃスピーカーも集まって大成功を飾れました！

5年間やってきたことで

• やって良かった取り組み
• あまり良くなかった（効果がなかった）取り組み
• やることこんな良いことがあるよ！

などなどを話していければと思います！是非に！

「なんかXXXの機能が開かないんだけど、、」
深夜に自分がリリースしたものが原因で次の日に全企業に響く様な障害を起こしてしまいました。

本トークでは以下の2軸をお話していきたいと思います。

■ なぜ障害が起こったのか
根本原因は「フレームワークの機能を使わなかった」からなのですが、なぜそうなってしまったかを
実際にコードリーディングしながら解説します。

■ 我々の組織の障害フロー
障害かな？から障害対応、そのあとのポストモーテム方法を取り決めています。
これにより良くなったこと・改善できたこと、などをご紹介します！

自分が起こした障害ゆえ発表するのも恥ずかしいのですが、、、言わぬは一生の悔い！！
ぜひ今後の人生の教訓にどうぞ。

Laravel sail を使っている方なら、一回は目にしたことがある Mailhog。他にも MailCatcher といったローカルでメール送信のテストをすることがあるのではないかと思います。
実際にこういった SMTP サーバーの役割を果たすものは使ったことがあるものの、どういう仕組みでメールのやり取りがなされているのか
興味がある方もいらっしゃるかと思います。
そこで、本トークでは SMTP サーバーとしてのプロトコルの解説から、PHP だけで SMTP サーバーを作るにはどうしたらよいのか、テクニックも含めて解説します。

ほぼエンジニアがいない状態からある程度の人数までスケールした組織で、コードの変化や Developer Experience がどのように
変化したのか、時系列で語られることはそうそう多くないです。採用から始まり、プロダクトを作っていく過程で、避けて通れないのが組織の成長です。
少ない人数では上手く機能していたのに、エンジニアが増えた途端、組織が機能しなくなったという話もよく耳にします。
そこで本トークでは、組織規模が大きくなるにつれて、実践した Developer Experience への取り組み、取り組んだ結果、どのように PHP で書かれたプロダクトに影響が及ぼされたのか、ノンフィクションでお話します。

何度も遭遇する PHP の「Allowed memory size of ...」。しかし、結局解決方法がわからず、最後には「ini_set('memory_limit', -1)」でその場を凌ぐという苦い経験をした方も多いのではないでしょうか。
PHP ではガベージコレクションもそれなりに発達しており、メモリを気にしないで書けるから良いと思っている人も少なからずいらっしゃると思います。
しかし、裏を返すと、メモリについてあまり考える機会がないとも言えます。PHP7.4 から弱参照といった機能も入り、メモリ管理に少しずつ関心が寄せられてきているのではないかなと思います。
そこで本トークでは、PHP でどのようにすれば省エネにメモリを使えるか、書き方のヒントまで含めてお話できればと思います。