Laravel Dacapoという自作のOSSライブラリの話をします。
https://github.com/ucan-lab/laravel-dacapo

・開発初期段階のマイグレーションについて
・マイグレーションで困っていること
・ダカーポを導入するメリット
・簡単な使い方やコマンドのご紹介

Laravel Dacapoという自作のOSSライブラリの話をします。
https://github.com/ucan-lab/laravel-dacapo

・開発初期段階のマイグレーションについて
・マイグレーションで困っていること
・ダカーポを導入するメリット
・簡単な使い方やコマンドのご紹介

「この仕様書通りにAPI作成をお願いいたします！」
クライアント様から頂いた仕様書、そこに記述されていたのは……

・数値なのに文字列型パラメータ
・カンマ区切りのジェイウォークなパラメータ
・mail_1, mail_2, mail_3 というマルチカラムアトリビュートなパラメータ
・"True", "False" という文字列型フラグパラメータ
・備考に「拡張用」と記述されている、現状無意味なパラメータ

本LTでは、そんなアンチパターンなリクエストパラメータの整形をサービスクラスではなく
Request クラスにアクセサ機能を追加するパッケージを作って整形したお話をします。

作成したパッケージ laravel-add-formrequest-accessor
https://qiita.com/kazumacchi/items/aebfe8dfccbfd28acaf4

皆さんお世話になっているPHP、そのソースコードを読んでみませんか？

プログラミング言語のソースコードを読むのはハードルが高いと思われがちですが、方法さえ知っていれば意外と読めたりデバッグできたり簡単な改変もできちゃったりします。

本トークではphp-srcを読む上で必要なC言語の知識から、php-srcのコードの構成、ビルド・デバッグの方法などphp-srcの読み方をご紹介します。プログラミング言語のソースコードを読むのは夢ではありません。PHPの深淵の入り口に招待いたします。

GraphQL初心者向けに下記のような話をします！

・GraphQLとは何か
・GraphQLのクエリ、ミューテーションの説明
・クエリの記述方法の説明
・Laravelでの導入方法
・実務で使ってみてどうだったか？

PHPからもC#のライブラリを呼べるようにした dotnet_ffi という PHP Extensionをつくりました。
C#側で処理することにより15倍ほど処理が高速化できたり、
UnityなどのC#で書かれるクライアントと処理を共通化したりといった用途を想定しているExtensionです。

このdotnet_ffiをどのように作ったのかを解説したいと思います。
現状例えば下記のようなトピックを考えています
・動機(なぜ作ろうと思ったか)
・Extensionを作るにあたって公式ドキュメントが不足しているのでPHPのソースを追った話
・CからC#を呼ぶCoreCLRの使い方とPHP Extensionへの応用の仕方
・ExtensionのPHP8対応のポイント
・できるだけPHPバージョンアップ時に修正が少なくなるようなExtensionの設計
・PHPのFFI機能との違い

dotnet_ffiソース
https://github.com/pg-ito/dotnet_ffi

概要

私が Symfony フレームワークを使っているとき、たまに目にしていた Serializer （シリアライザー）という言葉。これはフレームワークの一部でもあり、独立したライブラリでもある「Symfony Serializer Component」がその実体です。

Serializer が「PHP オブジェクトと JSON や CSV などの各種フォーマットとの相互変換をするもの」というのは、すぐに理解できるのですが、その使い方や応用方法については、ドキュメントを眺めてもパッと理解できるものではありませんでした。

それもそのはずで、公式ドキュメント [1] には「Serialization is a complex topic （シリアライゼーションは複雑なトピックです）」と書かれています。複雑な処理に関してのライブラリなので、理解にもちょっと手間がかかるというところでしょうか。

PHP での開発現場では、オブジェクトから JSON や CSV に変換したり、その逆を行なったりすることも多いと思います。そのような基本的、かつ、少し面倒な処理は、信頼のおける Serializer ライブラリ [2] に任せ、自分の時間はその他の重要なビジネスロジックの設計や実装に使いたいと思いませんか？

このトークでは、その複雑な内容を紐解き、Serializer Component についての理解を深めることにチャレンジしてみようと思います。

対象者

• PHP オブジェクトから JSON や CSV を出力する処理を書いたことがある開発者（フレームワークは問いません）
• 既に Serializer をマスターしている方も、発表者が間違った解釈をしていないかどうか、チェックしてくださると助かります 🙂

参考リンク

1. 公式ドキュメント
2. Serializer Component は多くのプロジェクトで採用されている

資料

• 発表スライド
• サンプルコード

Laravel では CSRF 攻撃対策としてデフォルトで CSRF トークンの検証をミドルウェアで行います。テスト実行時は利便性のために無効化されますが、心配性な私は、誤ってこのミドルウェアを外してしまって CSRF 脆弱性を埋め込んでしまうのではないか？と心配になり、一部のテストで有効化したいと思いました。

このセッションでは Laravel の CSRF トークン検証のテストを作成するまでの過程を追ってみようと思います。

みなさんは Feature Flag (Feature Toggle) についてご存知でしょうか？

コード中に Feature Flag の値による条件分岐を仕込んでおくと、その値を切り替えることで機能を有効化・無効化することができます。 Feature Flag を使うことで、機能リリースのタイミングの柔軟な制御や問題のある機能の迅速なロールバックを実現できます。

弊社では Feature Flag を使った開発・運用を1年以上続けてきました。その過程で、 Feature Flag を用いたコードのメンテナンスコストを下げるための工夫や、当初は想定していなかった方法による Feature Flag の活用を行ってきました。

このセッションでは、弊社の事例を中心に以下のようなテーマでお話しします。

• Laravel での Feature Flag の実装例
• 不要になった Feature Flag の条件分岐コードを機械的に削除する
• Feature Flag の値ごとのテストを作成する
• Feature Flag を使って機能のリリースを Slack へ通知する
• Feature Flag を使ってデータとコードの変更を同じタイミングで実行する

Psalm（サーム）はコードの問題を見つけてくれる静的解析ツール（PHPStan的なもの）です。

PHPでは、せっかく型を宣言しても実行してみるまでエラーに気づくことができません。
では、型を宣言することに意味はないのでしょうか？
そんなことはありません。
コードを実行しなくても静的解析がエラーを検出してくれるからです。

そんなPHPの開発に欠かせない静的解析ツールですが、どのような仕組みで動いているかご存知でしょうか？

先日Psalmにコントリビュートしたのですが、職場でEMになり手を動かす機会が減ったため、コードを書く機会を作りたいというのがそれを始めるモチベーションの一つでした。しかし、実際には仕様を理解するためにコードリーディングに多くの時間を使いました。せっかくなので、これからPsalmに触れてみたい人がコードを理解するのを助けるために私が費やした時間を捧げたいと思います。

誰向けのセッション？

• 静的解析の仕組みに興味がある方
• 静的解析のルールを作ってみたい方
• PHPStanやPhanは知っているが、Psalmって何かね？という方

本セッションの目指すところ

• 静的解析の一事例であるPsalmがどのようにコードを解析しているのか、その原理を少し理解して喜ぶ。
• これからPsalmにコントリビュートしたい方や拡張を作りたい方のハードルを下げる。
• PHPStanやPhanをメンテナンスする方がPsalmの仕組みを参考にできるかもしれません。

かつて自分がPHP MeCab Extensionを実装したときはC言語でバインディングを書くのが一般的な方法でした。
しかしPHP 7.4からはFFI (Foreign Function Interface) が導入され、C言語を書かなくてもC言語で書かれたライブラリが利用できるようになりました。
php_mecabをFFIを使って再実装する実例を元に、以下の解説をします。
・FFIの基本的な使い方
・メモリ管理
・FFIでできること
・FFIでできないこと

昨今ソフトウェア開発においてモデリングの重要性が解かれています。
ですがそれらは業務知識に結びついた話になりやすいです。
対象への理解がないと自分ごととして捉えづらい（ピンと来ない）でしょう。

そこで理解しやすい図形「三角形」を題材にし、共通認識をもったうえでモデリングの練習をしてみましょう。

大企業から中小企業まで、多くの企業につかわれています。
IoTや社内情報共有、QAシステム、マーケティング管理で使われています。
現在どのように使われているのかを説明します。

今までVSCodeしか使ったことがなく新しいエディタに躊躇していましたが、新卒2年目の4月からPhpStormを使い始めました。
PhpStormくんと仲良くなるまでにやったこと、仲良くなって初めて知ったPhpStormくんのスゴいところをLTでお話します。

サイボウズのGaroon（ガルーン）は今年で20周年を迎えるグループウェアです。
このセッションでは、20年にわたって開発が続いている巨大なレガシープロダクトのPHPバージョンを7.4から8.0にアップデートした際に得られた知見についてお話しします。

Garoonはさまざまな組織を支えるグループウェアであり、お客様の業務にまつわるデータをお預かりする性質上、セキュリティの確保が重要な課題です。
そのため毎年欠かさずにPHPのメジャー／マイナーアップデートを行い、常に最新のセキュリティ更新を取り込める状態を保っています。

しかしGaroonはPHP4系の時代から脈々と開発が続いているため、コードベースは巨大でありレガシーなコードが多分に含まれています。
さらにPHP本体にパッチを当てて自前でビルドしていることもあり、PHPのバージョンに対する依存度も高いです。
今年はPHP7.4からPHP8.0という影響の大きいアップデートを計画したため、約一年かけて準備を行なってきました。

その中で、比較演算子の問題をはじめとする、特に対処が困難であった以下のトピックについて詳しくお話しします。

• 厳密でない比較演算子の挙動変化を検出する仕組みの作成
• シリアライズされたデータに対する比較演算結果の保証
• 標準ライブラリ関数の見落としやすい変更点

結果的に、紆余曲折ありつつもPHP8.0へのアップデートが完了できました。
GaroonのPHPをアップデートするために具体的にどのように準備をおこなったのか、またその中で得られた知見を共有することで、
これからPHP8系へのアップデートを行う方々の助けになれたら幸いです。

本トークではPHPを用いてソフトウェアシステムにおける大小さまざまな依存とその制御方法について解説します。

ソフトウェアシステムにおいて依存は重要な考え方です。
依存はさまざまな粒度で現れます。
比較的小さい単位であればオブジェクト単位で依存が発生します。
比較的大きい単位であればシステム単位で依存が存在します。

この依存を軽視するとさまざまな弊害が発生します。
たとえば、ビジネス的にクリティカルなモジュールがインフラ起因で大幅な改修を求められてしまう。
たとえば、インフラの乗り換えで大変な苦労をすることになる。
たとえば、あるチームに仕事が集中しすぎてしまい、待ち時間が発生する。
これらは依存が引き起こす弊害の一例です。

依存が弊害を引き起こすのであれば、依存を削減すればよいところですが、それは簡単な話ではありません。
なぜなら、依存は避けられるものではないからです。
ソフトウェアシステムを構築するうえでは、大小さまざまな形で依存が発生するものです。
避けようにも避けられない依存が随所で登場します。

依存が避けられないのであれば、私たちが取るべき手段は依存を御することです。

本トークではPHPプログラムを題材にプログラムレベルでの依存とその制御の仕方を解説し、それらをヒントに組織レベルの依存の制御方法についてお話します。

アジェンダ

• 依存とはなにか
• 依存関係逆転の原則
• 組織レベルの依存
• 組織の依存関係の制御

みなさんは、外国のチームと開発 "オフショア" を経験したことはあるでしょうか？

オフショア開発では予想できないハプニングや思いがけないアクシデントが多々生じます。
私は現在所属しているチームに参画して以降、PHPでの開発を共に進めているオフショア先のベトナムチームとの窓口を4年担当し、
情報共有不足による失敗や、遠隔メンバとの距離感や温度感の違いによる認識齟齬をはじめとする様々な出来事を経験しました。
また、PHPでの開発を行う場合は、PHPを扱っているからこそ起きる "設計者が意図していない実装" にも意思疎通に障壁がある中で対応する必要があります。

4年担当した今でも、基本的な確認事項などを抜かしてしまうだけで、予想外の事態が発生します。
本セッションでは、そんなオフショアにおけるハプニングやアクシデントを紹介し、それらを回避するノウハウなどを実例を交えてお伝えすることで、齟齬の発生しないコミュニケーションや、相手への意図の伝え方をお伝えできればと思います。

システムで使われるエラーメッセージについて、こんな書き方は良くないというテーマで話します。
プログラム言語には依存しないため、PHPとは直接的な関係は無いです。

サービス開発するうえで、ユーザーや社内から様々のアイデアが寄せられます。
しかしいつだってそれを全て作る時間はありません。

「まず作ろう」と時間を割いてなんとかリリースしたが、「作ったけど使われない」、「なんか思ったのと違う」となり結果、技術的負債を生み出してしまうことに。。。
みなさん、このような経験をしたことは多かれ少なかれあると思います。

私が所属するROXXの back check ではフィーチャートグルの「Experiment Toggles」の概念をベースに実装したフィーチャートグルの機能を使って、
そのアイデアに価値があるのかを素早く検証し、限りある時間の中で「早く安全に失敗し学ぶ」取り組みをしています。

リリースや、運用にといったフィーチャーフラグの代表的な使い方以外の、「価値の検証」を目的としたフィーチャートグルのお話をします。

こんな話をします。

• なぜフィーチャートグルを使うのか
• フィーチャートグルを実装するうえで気をつけていること
• フィーチャートグルを使ううえでの調整の話
• メリット、デメリット

話さないこと

• 使っているサービスの説明・使い方

みなさんは「初めて見るコードの仕様を爆速で理解したい！」と思うときはありませんか？
例えばプロジェクトに初参画したときや、使用しているOSSライブラリの調査をするときなど・・・

そんな時には既存のテストコードを活用すると便利です。
見通しの良いテストコードやテストケース管理は、テスト対象となるコードの仕様理解を手助けします。

今回のセッションでは、PHPUnitの実装コードや公式ドキュメントサイトを一切見ずに、
PHPUnit内で書かれているテストコードを読みながらPHPUnitの仕様を理解していきます。

当セッションはこんな方におすすめです！
・自分以外の人が実装したテストコードをあまり読まない人
・PHPUnitのコードを読んだことがない人