トーク

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

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

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

みなさん、バグ調査は好きですか？新人の頃にバグ調査がなかなか上手にできなくて手間取っている間に、ベテランの先輩が鮮やかにやりとげるのを見て、落ち込んだ経験のある人も多いと思います。
このトークではPHPer歴そろそろ18年の私の、バグ調査の時の目の付け所・思考過程を解説することで、バグ調査が苦手な方向けにやり方とコツをお伝えします。

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

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

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

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

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

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

このセッションでは、

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

を取り上げ、

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

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

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

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

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

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

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

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

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

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

このトークの対象

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

みなさん、バランスとってますか？

世の中にはベストプラクティスやパターン、フレームワークが存在しています。
しかし残念ながら、それに従うだけではお仕事が進みません。
わかっていながらも、アンチパターンを取らざるを得ない状況もあります。
今日もどこかで誰かが、苦渋の決断をしてバランスをとっていることでしょう。

本トークでは、その「苦渋の決断」「バランスをとる」をするための考え方をお伝えします。
【要はバランス】と強い先輩たちは言いますが、その「要」にまとめられているのは一体なんでしょうか？
生活のなかから見いだした善・悪と正・邪を軸に、プロダクトの進化とバランスについて探りましょう。

対象は初心者・初学者の方や、どのようにクラスを分けたらよいのか決められないような脱初心者を目指す方を想定しています。