トーク

Pull Request(PR)ベースでCIを回している時に、「ここのコードがおかしいよ！」と分かりやすく指摘が入るのは、飛躍的に開発者体験をよくしますよね。
cs2prは、そんな良い体験をサクッと提供してくれるツールです。
GitHub Checks APIを用いて、PRの該当箇所上に指摘内容を表示してくれます。
(Reviewdogなどを利用している方にはイメージしやすいかも知れません。)

PHPCS、PHP-CS-Fixer、PHPStan、Psalm 辺りにはもちろん標準で対応しています！
ちょっと手間を加えれば、PHPUnitでも同様に「結果をPR上に出す」ことが可能になります。

どんな事をしてくれるのか？どうやって使うのか？を紹介します！

突然、元気に呼びかけて申し訳ありません！
言いたいことは掲題のとおりでございます。

Web業界やソフトウェア産業、とっても忙しいと思うんですよね。
やる事が多い！巷では、やれアジャイルだ、リーンだ、DXだ・・・と騒がれて久しい。
なんでも、「コードを書いてりゃOK」ではないような雰囲気がムンムンしちゃって。
「視座の高さ」「視野の広さ」がより求められている感じがします。

そんな幅広い職業に居る我々の「生産性」ってなんでしょうね？
(私、ここ1年ほど、職場でそんなことばっか考えてる。)
そのヒント、書籍「LeanとDevOpsの科学」にあります。
価値を届ける、確実性を上げる、無駄を削ぎ落とす・・「それって何？」に真っ向から向き合った1冊です。
ソフトウェア開発の「生産性」について考える、「改善」について考える、そんな取っ掛かりになるように書籍の紹介をします。

「(登壇はしてみたいが)話せるネタがない…」と思った事はありますか？

「高度で専門的な内容でなくても、他の誰かにとっては嬉しかったり、興味深いものである可能性が存分にある！」というのが個人的な考えです。
何であれ「話してみたいな」と思ったなら、それは登壇への第1歩です！

このLTで、過去の経験・感覚を踏まえて、自分自身が「どう考えてネタ作りをしたか」をシェアしてみようと思います。
「なんだ、その位なら話せることがありそうだぞ！！」という気持ちになってくれたら幸いです！

届けたい人

• 登壇などをしてみたい！けど、どんな事を話せば良いのだろう…が不安な方
• 無限にプロポーザルを出したい人

届けたいこと

• テーマを考える際の着眼点
• 気楽にプロポーザルを出すぞ！というリラックス効果

話さないこと

• 資料の作り方やプレゼン術みたいなもの

コードレビューは難しいですね！
異なる考え方・レベルにある他者同士、ぶつかってばかりではいられないけど「何も言えない」のでは意味がない─
そんな複雑で繊細な仕事に、どう向き合えばよいでしょうか？

本セッションでは「レビューは何が難しくて、"怖い"のか」について考えます。
その上で、コミュニケーションやチーム作りの分野にヒントを求めて「明日からできそうなこと」を紹介します。

以下のような書籍をヒントの元として想定しています(一例)。

• アジャイルプラクティス
• 学習する組織
• NVC 人と人との関係にいのちを吹き込む法
• あなたのチームは、機能してますか？

お届けしたい事

• 「威圧したい訳ではない！でも妥協もしたくもない！！」を両取りするためのヒント

扱わない事

• プログラミングの知識、技術
• コードのクオリティを高めるためのノウハウ

Composerには、Pluginという仕組みがあります。
2.0が来るまでは、hirak/prestissimoにお世話になっていた方も多いと思います。(私もその1人です！！)

では、「どういうことが出来るのか」はご存知ですか？
知ることが全ての始まりです。
もしかしたら、あなたの仕事に革命を起こすような素晴らしい可能性が眠っているかもしれません。

「Composer Pluginとはなんだろう？」とイメージを掴むために、「どういう仕組みになっているのか」「どういう機能があるのか」を紹介したいと思います。

お届けすること

• Pluginの仕組みと概念を知り、開発者体験の向上を進めるための引き出しを増やす
• 実例を通じたPluginの効果・ユースケース

話さないこと

• Composerの基本的な使い方、仕組み
• Composer v1.xからv2.xへの移行

「バグやエラーだらけのソフトウェア」は、開発運用していて大変ですよね。
何をしてもどこかが壊れている、増え続ける問い合わせ‥そんな状態を抜け出したい！と思ったことはありませんか？

エラーやバグの退治に取り組みましょう。
「健全化」されたアプリケーションは、チームの自信や誇りに繋がります。
泥沼から、どうやって一歩を踏み込んで行くかを話します。

お届けしたいこと

• 「なぜエラーを減らしたいか」の理論的な背景、根拠となりそうな情報
  • エラーやバグがもたらす不経済
• 検知や修復を急ぐべき理由。遅れがどんな悪影響をもたらすか
• 組織としてエラーをどう減らしていくか・進め方
  • チーム一丸となって”エラーを減らす”ためのステップ
• エラー管理ツールの活用
  • Sentryを想定

話さないこと

• アーキテクチャや「良いコード」といった品質面の話

先行きの不透明な開発プロジェクト。
鳴り止まない障害アラート。
挙句の果てに、リリースした機能がユーザーにあまり使われていない！
そんな課題を解決すべく、ごく普通の PHPer がある日突然スクラムマスターに任命されて...！？

エンジニアがスクラムマスターに任命される。
まれによくあるイベントです。

このセッションでは、

• スクラムとは何か
• 冒頭で挙げた課題に対して、スクラムではどのように立ち向かうのか
• エンジニアとしてどのような能力をスクラムマスターに活かせるか
• 逆に注意すべきポイントは何か

といった内容を、 PHPer からスクラムマスターに転身した自分の体験を踏まえて紹介します。

中小ベンダーのエンジニアとして、有象無象のWebシステムの開発や保守に関わる中で、本当にあった、身の毛がよだつようなアプリケーション脆弱性のお話や、笑えないセキュリティインシデントのお話を、怪談風に（・・・の予定で）お話しします。

第一話は、他社から保守を（引き継ぎなしで）引き継いだ、証券会社の顧客向けマイページシステムが、恐ろしい脆弱性だらけだったお話です。

調査結果の一次報告のとき、「このことは口外禁止でお願いします。明るみに出ると死人が出ます」と言われたことが今でも忘れられません。

第二話は、WordPressサイトが攻撃されて相談を受けた数々の事例の中で、一番悲惨だったお話。

時間が許せば、自社のやらかし（未遂）事例などもお話ししようと思います。

定期実行を安定的に行おうとすると意外と考えることは多いですよね

私たちが提供しているサービスの裏側では毎日数百のコマンドが定期実行されており、その安定化に日々頭を使ってきました

本セッションでは、そんな私たちが遭遇した様々な定期実行に関する問題とその解決法、たどり着いた現在の構成に関してお話ししたいと思います

WordPress でサイト作って約7年、「WordPress 完全に理解した」の先に待っていた失敗事例を踏まえつつ WordPress が人類に提供しているあれこれを俯瞰します。
最後に、近年の CMS に求められている機能とからめて WordPress が愛される理由について持論を展開してみます。

昨今、RDBMSを用いてサービスを作ることは非常に多くあると思います。

堅牢なテーブル設計を行っておく事は非常に重要で、バグが生まれづらくなったり仕様変更にも強いなど得られる恩恵は多いです。
逆に複数の関心事が集まったテーブル設計を行ってしまった結果、データを取得する為のSQLがややこしくなったり、仕様変更に弱くなる事も多くあります。アプリケーションと比べてデータベースは寿命が長く、その頃にはリファクタリングすら着手する事が難しいという事も多いですよね。

本セッションでは、データモデリングを学んでいなくても致命的な問題が起こりづらいテーブル設計手法について大規模WebサービスのDBリファクタリングをやった経験を踏まえて紹介させて頂きたいと思います。

ソリューションドメインという単語をご存知でしょうか？
ソリューションドメインとはPHPのようなプログラミング言語やMySQLのようなデータベースといった技術に関するドメインですが、ソリューションドメインに関する知識が少ないと、不必要な複雑さをアプリケーションに持ち込んでしまったり、適切でないモデルを構築するハメになってしまうことがあります。

エンジニアであれば技術の勉強を通してソリューションドメインへの理解を深めているはずですが、このトークでは改めてソリューションドメインについてまとめたいと思います。

• ソリューションドメインとは何なのか
• 設計とソリューションドメインの関係性
• ソリューションドメインを学ぶことで設計にどのような影響があるのか
• どのような問題ドメインに対してはPHPを使わない方がいいのか

Webアプリケーションを長年運用していると、至る所でパフォーマンスの問題が出てきますよね
リリース当初は問題なく動いていたものが、突然動かなくなるなどの経験をした方も少なくないのではないでしょうか

私たちの運用しているLaravelアプリケーションも例外ではなく、稀にデータベースが悲鳴をあげたり、特定条件でアプリのレスポンスが遅くなったりという状況に遭遇する機会が増えてきました

そんな問題の特定・解消のために導入したのがDatadog APMでした
発行されているSQLの数や処理時間、外部APIのコールやphpの処理時間などのデータが全て見える化されており、非常にパフォーマンス改善しやすい環境を作ることができました

本セッションではそんなDatadogの導入までにやったことやDatadogを活用してどうやって改善を繰り返しているかなど、事例を交えてご紹介したいと思います

なんか純粋にSymfonyの好きなところをお話ししたいなーって思いました。

PHPのフレームワークはたくさんありますが、その中でもぼくはSymfonyが好きです。
Symfonyの好きなところを20分かけてお話しします。
みなさんにSymfonyって面白そうだなー、さわってみようかなーって思ってもらえるようがんばります。

みなさんよくご存知の通り、PHPには等価演算子が2つあります。
「==」と「===」です。
前者は緩やかな比較、後者は厳密な比較が行われます。
PHPやJavaScriptに馴染みのある方ならよくご存知だと思います。

言語問わずよく使う演算子の1つである等価演算子ですが、実際の言語仕様は知っていても
内部の実装は知らないなんてことはよくあると思います。

今回はみんな嫌いな緩やかな比較の実装がどこにあるのか、そしてどんな実装がされているのかをお話しようと思います。

プロジェクトマネージャー、なりたいですか？

いわゆる「PM」は「プロダクトマネージャー」と「プロジェクトマネージャー」の二つを内包することが多いですが、ここでは後者の「プロジェクト」をマネージする（なんとかする）人についてです。
前者の「プロダクトマネージャー」はPdMなどとも呼ばれ非エンジニアがなることも多いですが、プロジェクトマネージャー（以下PM）はエンジニアが担当することも多いのではないでしょうか。

プロジェクトには数日で終わるものも、数ヶ月かかるものもあるかと思います。最初は単に小さなタスクをこなしていたエンジニアがどうやったらPM（＝プロジェクトを"なんとかできる"人）になれる能力がつくのでしょうか？

本セッションではPMの仕事内容と、それに対応するスキルセットの身につけ方についてお話しします。

【注】会社によりPMの職務範囲は変わるので、私の観測範囲内でのお話です

PHPは動的型付け言語で型推論してくれますが、きちんと「型」があります。
昔のPHPでの開発は「型」をあまり意識せずプログラムすることが多かったのですが、
最近では保守性や堅牢性を重視するために、この点を意識して作ることが多くなっています。
今回のセッションでは、PHPの「型」の種類や使い方、メリットデメリットや実践について、わかりやすくお話しします。

エンジニア教育を事業としてやって一人エンジニアを2年やってきました。
その中で、

1. ユーザーの方が困ったこと
2. 運営としてやってみたこと
3. 現場に入ってもらう上で解決したこと

ということがいくつかあります。その辺りを共有することで、

1. エンジニアという職種を楽しめる人が増えること
2. 新卒教育で気をつけてもらえること

が進むのではないか？と考えていることをお話しします。
「リードエンジニアいねえ！」問題を解決する足掛かりになればなぁと思います。

Laravelでアーキテクチャをしっかりと決めずに開発を進めてしまった結果について話します。

• どの程度ルールを決めていたのか
• どの程度アーキテクチャをゆるふわしていたのか

と開発の変遷をお話しすることでだんだん 「疎結合で変更に強いアプリケーション開発」から離れる開発になっていくフローがどのようになるのかがわかるように話そうと思います。また、その結果支払うことになったコストがどれくらいなのかをまとめて話します。

PHP 8.1 から Fibers が導入されました。それ以前の非同期処理といえば、Swoole などが筆頭になっていました。
非同期処理ライブラリが PHP にビルトインされるのは PHP に革命をもたらしたと言っても過言ではありません。
しかし、Fibers ではできないこと、Swoole でできることなど、実際には分かれています。
そこで、Fibers と Swoole の違いはなにか、それぞれの使い方を広く浅く本トークで解説します。