一時期、ある理由から 「Laravel の blade ディレクティブって使わない方がチームの為になるのでは…？」などと血迷った考えが頭にありました。

blade ディレクティブを使わないようにするには、Laravel が blade ディレクティブをどのように PHP 構文にコンパイルしているか知らなくてはなりません。

コアコードやコンパイル後のコードを確認していくうちにその血迷った考えはなくなり正常な判断が出来るようになりましたが
今後一時的にでも同じように血迷う方が出ないようにその話をします。

プロダクト開発は楽しいですよね。楽しいです。チームメンバーと切磋琢磨しながら、品質やスピードを向上させていくことは非常にやりがいがあります。

しかし、他部署や非エンジニアと関わる場合、そのプロセスは容易ではありません。異なるバックグラウンドを持つメンバーとの協力は中々噛み合わず議論が平行線になるこも少なくないと思います。また、人対人でうまく目線があっても、部署や組織としてうまく合意形成がなされず、部署内で目線がずれることも珍しくはありません。
さらに、エンジニアだけ頑張ってもうまくいきません。開発したソフトウェアを利用し、現状を変える、売上を上げるのは現場の人たちなのです。反対に非エンジニアだけが頑張っても、やはりうまくはいきません。

本セッションでは、そんな現場でスピード感を持ったプロダクトを作るために必要なコミュニケーション方法について、具体的な事例を交えてお話します。

みなさん、PHP書いてますか？
趣味や業務、授業など、さまざまな関わり方があると思います。

このトークでは、シンプルに「新卒1年目が"初めて業務でPHPを触った率直な感想"」をお話しします。

現時点までに私が参加したPHPカンファレンスの総回数は8回！
趣味開発でPHPを使うこともなかった私は"これまでカンファレンスだけでPHPの情報を得ていた"と言っても過言ではありません。

学生時代からカンファレンスに参加していた私が"初めて業務としてPHPと触れ合った時"に何を思い、どこに驚いたか。
業務でPHPを実際に書いた後、カンファレンスでどんな感想を抱くようになったのか....など。
新卒の視点から、フレッシュなトークをお約束します！

話すこと

• PHPカンファレンスに参加した感想
  • 経験ゼロのとき
  • 入門あと
  • 業務で触ったあと
• PHPと実際に触れ合った感想

PHP 8.0 から比較演算子の挙動が変更になったことは有名ですが、今回は sort 系関数にフォーカスしてそのヤバさを語りたいと思います。
というのもその余波はPHP 8.2 にアップデートした際にも存在したのです。
具体的には ksort の仕様変更でガッツリ影響を受けてしまいました。
その際、ksort を 消そうっと いうのも考えましたが、とりあえず今回は そーっと しておくことにしました。
このトークではPHP 8 より前の sort はどうヤバいのか、PHP 8.2 アップデートでプロダクトにどのような影響が出たのか、についてお話しします。

■ 話すこと

• PHP 8 で比較演算子の挙動が変わったことによる sort 系関数への影響
• なぜ ksort krsort だけ PHP 8.2 で修正されたのか
• プロダクトへどんな影響が出たか

Composerは素敵なので、PSR-4ベースのオートローディングを提供してくれます。
否！PSR-4だけじゃなく…PSR-0、class mapベースだって出来ちゃいます。
でも、ComposerやPSR/PHP-FIGが生まれる前の時代から、 spl_autoload_register()は存在していた訳です。

「昔あったオートローダー」たちを見に行ってみましょう！
今や当たり前の「ComposerとPSR-4」以外の世界に触れることで、
日常を支える「How」についての解像度が上がるかも知れません。

こんなことを話します・触れます

• 超ざっくり「オートロードってどんな仕組み」
• 日常: PSR-4の世界
• 平成レトロ: PSR-0の世界
• 多様性: CakePHP2, Yii2, 旧Zend Framework2

「エンジニアは技術力があれば食っていける」というのは間違いです。

バグの詳細、進捗の報告、修正方針、時には障害の現状報告まで、エンジニアのまわりは他者へ伝えることで溢れています。
そう、チームとしてソフトウェアを開発する以上、エンジニアに求められるものは、プログラミング言語より先に日本語の技術です。

しかし、みなさんも報告したいことがあるのに相手へ伝わらずもどかしく思ったり、またはうまく伝えることができない人を見て歯痒い思いをしたことがないでしょうか？

本発表では私がカンファレンスでの登壇時や、仕事で実践している工夫をもとに、明日から使える伝え方のテクニックと考え方をお伝えします。
伝え方のテクニックは仕事だけでなく、PHPカンファレンス沖縄のようなイベントでの登壇時にも役立ちます！
このトークを聞いて、技術知識だけでなく、伝え方の能力も磨きましょう!!

「レガシーなコードは嫌」「リファクタリングして認知負荷の低いコードにしたい」と思っていませんか？
でもいざリファクタリングして、使ってないと思って消したコードが実は使われてて危うく障害になりかけたり、
テストコードを書こうにも、テストコードが書きづらいためにリファクタリングし辛いことも多々あるはずです。

このセッションでは、そういったレガシーなコードに対し、どのようにリファクタリングをしていくとよいか、具体的なテクニックについて話します。

話すこと

• そもそもレガシーコードをリファクタリングをするかしないかの判断
• 使ってなさそうな関数には生存確認のログ埋め込み
• でかい処理にはまず単純な関数分割
• 改修頻度が高く重要なロジックからテストコードを書く

プルリクのレビュー指摘対応おわり！静的解析もテストも問題なし！予定通りマージできそうだ。
お、新たにコメント来てるな。

「「「「この実装はドメイン層で持つべきではありませんか？」」」」

私のチームでは、このような指摘が時折発生します。
当然、そのたびに「このタイミングでなんてグッドアイディアが来るんだ！（悲鳴＆歓喜）」となります。
そしてリリースが遅延しかけます。

リリースの遅延を避けるためには以下のような葛藤と相対します。

早く提供して反応を見たい v.s. 特別対応で保守性を崩したくない
競合他社に負けないスピードで出したい v.s. 技術的負債を増やしたくない
などなど...

これらの問題に正攻法はなく、その都度数々のパラメータを元に優先度を検討して対応する必要があります。
簡単には答えを出せない葛藤にチームがどう対応したのか、リアルな事例を交えて紹介します。