トーク

PHPStanを入れる時の話です
既存のプロジェクト・・色々な歴史の重みを抱えるコードベース・・・さて、どうしますか？

よく「低めのLvから始め、教育と理解促進も図りながら徐々にLvを上げる」という手法が紹介されます
非常に健全で真っ当なやり方で、絶対良いです
が、皆さんの現場に於かれましては「そんなに忍耐強くやっていられぬ、いいからとっととやっちまいたい」という感情はないでしょうか？

このセッションは、そんな茨の道、ハードコアなスタイルを自ら選ぶように、”傲慢”・”短気”を包み隠さない人を応援します

ポイント

• 「現状に合わせて」ではなく「何を得たいか」から逆算すると、「まずLv0」は最適解なのか？
• baselineがデカい？そんなの関係ねぇ
• 誰もやらないなら自分で行く、という気持ちで既存コードをどうにかし続ける
• 少しでも気概を見せている人には全力で寄り添う

ここ数年、「(ラボラトリー方式の)体験学習」という概念と出会って、非常に面白いと感じているので紹介したいです
Webエンジニアやアジャイル(或いは志半ばの)チームにとって、学ぶ価値のある領域だと確信しています

例えば、ふりかえり。
「チームで集まって立ち止まる時間をとっている…しかし、次のアクションを出しはするのの、チームの考え方を変える様な気付きは生み出せていない！」
なんて事、ないでしょうか

生身の人間の集合である以上、議論には合理的で安定した判断以外も混ざります。どうしても人間関係や感情・感性が影響を持ちます
そうした内面的なもの・議論の中で言葉として表出され難いものをも含め、参加者同士で認め学び合うのが、体験学習の世界観です
それにより、いつもとは違う視点を引き出します

このセッションでは、体験学習のエッセンスに触れながら、チームの進化に向けたふりかえりの実現を考えていきます

privateメソッドのテストを書くか書かないか問題はよく話題にあがるかと思います。
実は、私もかつてはprivateメソッドのテストをたくさん書いていた時代がありましたが、今はprivateメソッドのテストは書かずにテストを書いています。
自分の思考の整理をするのに繋がった「単体テストの考え方/使い方」という本の内容からも引用しつつ、
実体験をベースに「なぜprivateメソッドのテストを書かないのか」というところをお話します！

トークで話す内容

• かつて私が書いていたprivateメソッドのテスト(と、その理由)
• なぜそれが良くなかったか？「偽陽性」「偽陰性」の視点から考える
• どのようにテストを書くべきだったか？
• privateメソッドのテストは書かない方がいいのか？(※経験に基づいた持論)

platform.shを知っていますか？
platform.shはherokuやvercelのようなPaaSサービスです。Laravelも使っているSymfonyコンポーネントの作者であるfabpotも参画しており、PHPを動かすのにも最初から対応しています。
何ができるの？どう使うの？日本語対応してるの？料金いくらぐらい？
自腹を切って実際に使ってみた体験記をお話しします。

LaravelにはFacadeというものがあり、

DB::select('select 1');

というように利用することで処理を実行できます。
しかし、よくよく考えるとなぜこれが動くのか、きちんと理解して使っているでしょうか？

このLTでは「Facadeがなぜ動くのか」を理解したうえで、「Facadeは極力使うべきではない」という意見について、「なぜなのか？」を話したいと思います。

Laravel Breezeとgoogle2faを用いた設定を行うにあたってやったことを、実際に作ったものも踏まえてご紹介します。

システム開発を行う上で必ず存在するもの、それは組織です。
そして組織には人の出入りがつきものです。
しかし、入る人間よりも出る人間の方が多いと次第に組織運営は立ち行かなくなってしまいます。

このトークではなぜ人は組織から去っていくのか？を自身の経験＋書籍『エンジニアリングマネージャーの仕事』をもとに考察した結果をお話したいと思います。

具体的な内容

• 自身の経験に基づく、組織を去るときのマインド
• 書籍『エンジニアリングマネージャーの仕事』に基づいた、「エンジニアリングマネージャーが与えるべきもの」
• 自身の経験と書籍『エンジニアリングマネージャーの仕事』で語られる「人が去っていく理由」を照らし合わせた結果

対象者

• 現在進行形でエンジニアリングマネージャーの方
• 長く一緒に働いてくれる同僚を探している方
• 転職を考えている方

世の中には素晴らしいプログラミング言語がたくさんあります。

少ない記述量で豊富な機能を持つもの、洗練された美しい構文で誰でも明瞭なコードが書けるもの、コンパクトで一貫性のある構文と標準関数を提供するもの、簡潔な記述で強力な型を提供するもの… それに引き換えPHPは、一般にとても洗練されていない方のプログラミング言語という風評があります。

このトークにおいてはプログラミング言語としてのPHPの歴史的経緯、そしてなぜ現在でもそんな言語の使用が正当化されるというのか、または私は如何にして心配するのを止めてPHPを愛するようになったかについて語ります。

複数のプロダクトやサービス事業を展開している企業で一度は言われる「共通基盤を作りたい」。
近年、エンジニア側も「よし、共通基盤だ！マイクロサービスを作ろう」と安易に呼応してしまうことがでてきました。このように始まったマイクロサービス開発では、往々にして失敗したマイクロサービスが負債として残り、エンジニアチームは「マイクロサービスはダメだ」という感想を持ってしまいがちです。

「共通基盤だ！」と言い出したとき、本当にマイクロサービスが必要だったのでしょうか？
前職で数年にわたってマイクロサービスを開発・運用し、PHPerKaigiでマイクロサービスを布教したこともある私ですが、現職では「共通基盤だ！」にNOを突きつけています。
共通基盤というマイクロサービスがほしくなる動機を解きほぐし、マイクロサービス採否ジャッジの基準、ニーズをマイクロサービス以外の方法で満たす方法についてもお話しします

テストを書くとき、テストデータ（テストフィクスチャ）をどのように用意していますか？プロダクションコードを改修するとき、テストフィクスチャにも多数の改修作業が発生してつらくなっていませんか？
私は10年近くテストのある開発をしてきた経験から、テストフィクスチャもオープン（拡張に対して開いている）で、クローズド（修正に対して閉じている）にするのが良いのではないかと思うようになりました。
このトークではまず様々なテストフィクスチャの作り方を概観した後、オープン・クローズドなテストフィクスチャを実現するために現時点でベストだと私が思う方法をお伝えします。

テスト駆動開発(TDD)はしばしば、現代的な開発における強力なツールとして紹介されます
TDDのバイブルとして、t-wadaさんの再翻訳でもお馴染みの『テスト駆動開発』は外せません

もう1つ、TDDの世界観に立ち新たな開発手法を提案する書籍が『実践テスト駆動開発』です
こちらの書籍では、いわゆる「単体テストの2つの流派」のうち、「ロンドン学派」のスタイルを実践されています
古典派的な「下(中身)から作る」だけではない「上(外)から作る」感覚が身に付くでしょう
───場面に応じてスタイルを使い分ければ、開発が進め易くなります！！

もっと簡単に、もっと自由に開発を進めたくないですか？

このセッションでは、

• 「外側から作る」なTDDの世界に触れてみる
• 普段の開発に軽い気持ちで活かしてみる

を取り上げ、

• 柔軟性を手に入れプログラミングを楽にする

ためのヒントを提供します。

話者はPHPカンファレンス2023にてフレームワークを作成します
その結果のLaravelやSymfony、CakePHPなどのフレームワークに敬意を払わずにはいられない様になりました

作成する中でわかったフレームワークを作る上での勘所や課題を共有します。

フレームワーク作者の思考を、フレームワークを作成する側から覗いてみる事で
少しでもその苦労と知見を共有出来ればと思います。

• お話すること
  • フレームワーク作成時の思考
  • フレームワーク作成で困ったこと
  • フレームワーク作成の楽しさ
  • フレームワーク作者への敬意
• 対象者
  • フレームワークが好きな人
  • フレームワークの中身を見てみたい人

「良いプロダクトを作るためにもっとエンジニアとビジネスサイドで協力していきたい！」
その想いを胸に半年前からスクラムを使ってプロダクトを作っています。

それまではエンジニアとビジネスサイドが同じチームで深く関わって仕事をすることがあまりありませんでした。
スクラムを入れる上でコミュニケーションの取り方をガラっと変えたかったのですが、ちょっとハードルが高いかもな、、と感じました。

そのため最初は敢えて「不完全」な形式でスクラムを始めました。
スクラムの良さをチームで実感するにつれて、徐々に「完全」なスクラムになっていきました。
そして今は「チーム全員で良いプロダクトを作っている」という感覚があります。

本トークでは、どのようにスクラムの体制を改善していったのか実体験をベースにして紹介します。

このトークの対象

• スクラムに興味がある人
• 組織的な課題でスクラム導入に悩んでいる人