トーク

phpstan/phpstan-strict-rules というパッケージがあります。
これは、PHPStanに「より厳しい」規約を追加しちゃうよ！！！というものです。

コーディング規約の理想は「良いコード(とチーム開発)」の実現であり、その中には「断言的であること」「記述がコンパクトであること」などなどが含まれていると思います。
これは「不吉な臭い」を避けるtips集としての効果もあります。

開発者が不吉な臭いを発するのを避けたい・・・そうした方向性の進化は、PHP自体も歩んでいるところです！

「良いコード」を標榜するチームのためのphpstan-strict-rulesと、「PHP7の後半や8で出来るようになったこと」を一緒に眺めてみましょう。
今っぽいPHPでの「当たり前」を見出したり、「PHPって便利になったね！」という喜びを分かち合いましょう。

多くの Web アプリケーションでは一度開発したらそのまま運用を続けていくことはなく、変更や追加開発を続けていくことになります。
変更は避けられないものでありますが、無秩序に変更を続けていくと複雑度が増し、変更するのがより困難になっています。
変更したら思いも寄らない箇所に影響があって冷や汗をかいた経験がある方も多いでしょう。

本セッションではこの変更容易性に着目して、設計や実装において変更容易性を高めるための手法を考えていきます。

初めて作られた時にはピカピカと輝いていたソフトウェアも、時が経つにつれて「劣化」していきます。
うまく使われれば機能は増えていきます。コード量も育っていきます。そこが問題です。
増殖していくコードたちを、誰が・いつ”良く”するのか。

実行するには、組織内にマインドとスキルの両方が必要です。
それらを育むには、どこから取り組んでいけば良いでしょうか？
本セッションは、「なぜソフトウェアが『劣化』するのか」「それを解消するためにどんな事を狙っていくか」と、そこから演繹して「自分自身の取り組んでみたこと」を紹介します。

まだまだ取り組みの最中なので、必ずしも「成果」をベースに語れるものではありませんが、何かしらのヒントになれば幸いです。
また、オーディエンスの皆さんからのフィードバックをもらったり、そこから更に踏み込んだ議論が生まれていくことを期待しています。

紹介するお話

例えば、以下のような取り組みが「自分なりに考えたこと」でした。

• 「技術力」を定義する
• プロダクトと技術力の関係
• 自分自身が「技術的な成長」を感じた瞬間を構造化して捉える
• その「良いフィードバックの獲得の仕方」を組織的に再現できないか？

こうした話を「議論のネタ」として提供したいと考えています。

この課題を選んだ背景

プロダクト開発や(Web)サービスの提供を行う会社において、
Webエンジニアに求められる主要な成果は「プロダクトを良くする」ことだと思います。
プロダクトをよく出来るエンジニアとは、どういう存在でしょうか？
実は、「プロダクトをよく出来るエンジニア」になるには「プロダクトを開発する以上の技量」が要求されるのではないでしょうか。

ここには大きな矛盾があると考えています。
「プロダクトを良くし続けるには、プロダクトに必要なレベルの技量では足りない」という矛盾です。
これについて、自分自身が、所属先の企業でのロールが変化したのをきっかけに取り組むようになりました。
組織の姿が「プロダクトを作れる」を超えた「プロダクトの未来を作れる」ようになるにはどうすればよいか・・？と現在進行系で考えています。

話者はPHPerですが、なんとなく全部出来るからという理由で
渡されるインフラの整備に疲れている時期がありました。

そんな中メンテナンスフリーと言われてきたサーバーレスという技術に興味を持ち
今では全てがAWSのマネージドサービスにて構成されているアプリケーションを作成する術を身に着けました。

それは話者の悩みを全て解決するものではありませんでしたが、
本来解決したかった以上の課題を解決し、初期認識よりも出来る事の幅の広さも感じました。

PHPerがフルサーバーレスアプリケーションを構築出来るまでに至った軌跡をなぞり、
メンテナンス、コスト、疎結合化などのメリットやデメリットについてお話します。

■想定する聴講者
　- サーバーレスアーキテクチャに興味がある方
　- サーバーレスアプリケーションの開発フローに興味がある方
　- サーバーコストを最小化したい方

■お話しないこと
　- PHPを中心としたアーキテクチャ
　- 完全なメンテナンスフリーインフラを手に入れる事

コンテナは便利、開発環境の構築から本番の運用まで様々なメリットがあります。

そんな中Dokcerを使った開発を行っている中で発生する、
パフォーマンス問題などのデメリットが存在するのも事実です。

今回はパフォーマンス、テスト実行まで意識した
Dokcerの開発環境整備について解説したいと思います。

不便な点もあるけど便利だから我慢しているという方に
少しでも快適なDokcerライフを送って頂ける一助になれば幸いです。

■想定する聴講者
　- Dokcerを使って開発しているPHPer
　- CircleCI等を使ってCI/CDを回している方

■お話しないこと
　- ProductionへDeployするためのテクニック
　- Windows、Macにおける細かな違い

皆さんLaravelは使っていますか？私はここ数年Laravelを使ったアプリケーションばかり書いています。
Laravelでの開発を続けていると、やりたいことがドキュメントに載ってない！ということが結構あると思います。しかし、LaravelのIlluminateにはドキュメントに詳しく説明されていないInterfaceやLibraryがあり、これを実装したり継承したりすれば、かゆいところに手が届くということが多々あります。このような例を実例と合わせて複数紹介させていただきます。

「この機能をリリースしたらユーザーって増えるの？」

・・・・・・・・・

「〇〇したら☆☆になる」が100発100中でできる人がいたら申し訳ありませんが、プロダクトづくりにおいてなんらかの問いに対して正解を持っている人はいないように思います。
しかし、「誰も正解をもっていないものをそれでも形にする」ということがプロダクトづくりをはじめ我々の仕事では求められるケースが少なくないと思います。
プロダクトづくりの「不確実性」は日々新しい技術が出現したり、ユーザーが持つ課題が多岐に渡ったり、関わるチームメンバー・ステークホルダーが様々だったりなど様々な要因がそうさせるのではないかなと思います。
そんな中、少しでもプロダクトを前進させるためにできることは仮説を立てその検証をするというプロセスをいかに素早く回していくかというのが大事ではないかと感じています。
さらにそれは自分1人で完結できるものではなく、チームの力が必要です。
現在わたしの現場ではスクラム開発を取り入れプロダクト開発を進めておりますが、よりよいコミュニケーションでよりよいプロダクづくりをチームでするためにやっていること、工夫してみていることを共有させていただきたいと思っています。

みなさんの現場では1on1は行われていますでしょうか？
わたしの現場では2週間に1回の頻度で1on1を行ってきました。
1on1回数を重ねていくごとに、エンジニアリーダー的な立場でメンターとしてメンバーと1on1を行っていた場合は、「この1on1は相手にとって有意義なものになっているのだろうか？わたしの自己満足になっているのでは？」と思うようになったり、逆にわたし自身がメンティーとして上長と1on1する際には「自分にとってはいい1on1になっている気はするけど本当にそうだろうか？上長にとっても期待した1on1になっているだろうか？」と考えモヤモヤしていました。
1on1の実態がお互いに期待している効果を生み出していないとするとそれはとても残念なことであり時間も無駄になってしまいます。
一般的にはチームビルディングやコミュニケーションの促進のために行われる1on1ではないかなと思いますが、現場によっても多少のニュアンスの違いは生まれるでしょう。また、1人1人のメンター・メンティーが1on1に期待することにも違いがあると思います。
そのような期待値の調整をするために1on1のふりかえりを行っているのですが、このセッションではわたしの現場で1on1ふりかえりをどのようにやっているのかを共有させていただきたいと思っています。

bugs.php.net は PHP の公式 issue トラッカーで、処理系本体と公式バンドル拡張、PECL 拡張をあわせて現在 2000 以上の未解決のバグが登録されています。

古いものでは PHP4 時代のチケットで残っているものもあり、現在サポートされている処理系バージョンにおいてすでに解決済のものや、そもそもバグではないもの、当初は明らかにバグだったとしても 10 年以上その挙動が続いたことで、もはや仕様としてしまった方がよいのではないかと疑われるものなど、色々なチケットがあります。

そんな bugs.php.net の古くからある塩漬けチケットについて、現在サポートされている PHP 7.4 以降でも再現するか、レポート内容が妥当かなどを検証しつつ、修正可能なものについては PR を投げ、修正不可能であったり修正の必要がないものについてはコメントを追加して現在の状況を付記する、という清掃活動に取り組んでみました。

bugs.php.net 自体やチケットの調べ方について紹介しつつ、見つけて面白かったチケット、実際に対応したチケットについてお話します。

日々の業務の中でコードレビューは頻繁にされているでしょうか？
コードレビューは好きでしょうか、それとも嫌いでしょうか？　もしくは、得意でしょうか、苦手でしょうか？

コードレビューはどうしても負担になる作業であり、誰が誰のコードをレビューするかによってその負担量も大幅に変わってきます。
また、レビューによって見つけた問題点をどうやって指摘するかによって、今後のコミュニケーションに影響を与える可能性があると言っても大げさではありません。
私自身コードレビューは好きという変わったタイプではあるのですが、細かい指示ばかりで本質を見失ってしまったり、指摘の仕方を間違ってしまったと後悔したり、レビューを妥協して良くないコードを世に放ってひやひやしたり、反省すべきことはたくさんあります。

良いコードレビューや悪いコードレビューの経験は誰しもがあるとは思いますが、本セッションでは良いコードレビューとは何かということを話したいと思います。
特に、以下のような内容について紹介します。
・良いコードレビューとは何か
・良いコードレビューをするために心がけるべきこと
・悪いコードレビューとは何か
・悪いコードレビューをしないために心がけるべきこと
・コードレビューを依頼する側の話
・コードレビューの負担を少しでも減らすために

Composer で見かける「PSR-0」「PSR-4」、コーディングスタイルでみかける「PSR-2」「PSR-12」など、PHP に関わっていると自然と目にする「PSR」という言葉。
「PHP Standard Recommendation（標準勧告）」の頭文字なのですが、果たしてこれは何なのか？使い方は？どんなメリットがあるのか？
そんな疑問に対して、具体的なコードとともに解説していきます。

フレームワークのバージョンアップだとか、新しいコーディング規約の導入だとか・・・
コードをメンテナンスしているとどうしても避けられない「面倒くさい作業」ってありますよね。

その作業の一部で、よしなに機会がやってくれたらどんなに素敵でしょう？
PHPには、そんな「些細なリファクタリング」を手助けしてくれるツールが複数あります。
使いこなせれば、あなたのチームを「面倒」から解放してくれることでしょう。

このセッションでは、いくつかのツールを取り上げながら「仕組み・原理」と「活用・カスタマイズ」について紹介します。
具体的には、Rector, PHP CS Fixer, EasyCodingStandardを想定しています。

「一括してコードを綺麗にしたい」という人たちのために、「ツールの基本利用やオレオレルールの作成」までお届けして、退屈な仕事を減らす！！ことができれば幸いです。

みなさんはカンファレンスで登壇したことがありますか？
カンファレンスで登壇をしているスピーカーは、様々な過程を経てみなさんの前でトークをしています。例えば採択前ならネタ決めやプロポーザル、採択後ならスライド作成・トーク練習などの準備・・・
このトークするまでの過程は、人によって違うところもあり暗黙知であることが多いように思えます。

そこで今回は、過去に私がPHP系カンファレンスにて登壇した内容を例にしつつ、自分がカンファレンスで登壇するまでに準備していることを話します。
あくまで私個人の例ではございますが、少しでも登壇に対する暗黙知をなくすことを目的としてトークします！
まだ登壇したことがない方はもちろん、登壇したことがある人も良いところを取り入れられるきっかけになれば幸いです！

具体的には以下のことについて触れる予定です！
・プロポーザルを出す時にどんなことを考えているのか？
・無事採択されたけどトークするまでの準備はどういうことをしてるのか？
・過去に採択されたことのあるトークを例に具体例を紹介

多くの場所でジェンダーに関する話題が議論されるようになり、ITコミュニティでも無意識バイアス、ハラスメント対策などエンジニアの女性比率を高める為の取り組みに注目があつまっています。

これらの議論の中ではしてはいけない行動がなにかといったことが多く話題に上がる一方で、ではどのような行動をすればいいのか、また男性エンジニアの文化そのものについてはあまり話題に上がりません。

このセッションでは「男性エンジニア」とそれを取り巻く環境と文化とはどういったものなのかを考察し、より多くの人に対してインクルーシブなコミュニティや職場を作るために男性エンジニアがどのような行動を取れるのかについて紹介します。

トーク内で取り上げる予定の話題

• ロールモデル
• 無意識バイアス
• 心理的安全性
• Cultural Water
• アライシップ
• ジェンダーギャップ
• Michael Welp : White Men: Time to Discover Your Cultural Blind Spots
• Tony Porter: トニー・ポーター：男達への提言
• ジェラルド・ワインバーグ: プログラミングの心理学
• イリス・ボネット: Work Design

Webサービスを運営していると、サービスからユーザーにせっかく送ったメールが届かないことがあります。
そのような、何らかの理由で目的のユーザーの元に届かなかったメール＝バウンスメールをどう処理するかは、サービスにとって避けては通れない課題なのではないでしょうか。
また、AWS SESを使っている場合、バウンスメールの数が多すぎるとペナルティがあったりするなど、サービスにとってバウンスメール処理は意外に大事なものだったりします。
このセッションでは、そもそもバウンスメールとは何なのか、バウンスメールを適切に処理しないとユーザーそしてサービスにどんな不利益があるのか、またBASEのバウンスメールの処理に関する知見と実際の実装について、お伝えしたいと思っています。

LaravelのフォームリクエストのprepareForValidationでは
バリデーションを実行する前にリクエストデータを加工することができます。
リクエストデータを小文字に統一することや
[name=month value=10]、[name=day value=2]の2つリクエストデータを
[name=date value=102]という1つのリクエストデータにmergeすることができます。

ですが、prepareForValidationでmergeして新たなリクエストデータを作るとテストがしにくなってしまうのです。
基本は、Laravelのフォームリクエストをテストするとき、
Validatorファサードでバリデーションインスタンス生成して
passesメソッドに想定していデータを受け渡して確認するのですが、これが使えなくなるのです。

こういった場合のテスト方法として、以下の3つが考えられます。

1. Validatorファサードを使わず、自己流でバリデーションインスタンス生成してテストする
2. フォームリクエスト単位ではなくFeatureTestとして大まかにテストする
3. Laravel Duskを利用したE2Eテストで大まかにテストする

それぞれについて試した結果について話します。

本セッションでは主にLaravelのフォームリクエストとテストについて話します。

PhpStorm 使っていますか？
ご存知の通り、PhpStorm は、開発を効率的に進めるための機能がたくさん搭載されており、PhpStorm を使いこなして開発を進めている人の作業を見ると、素早いコーディングに驚かされると共に、自分も同じように PhpStorm を使い倒したいと憧れます。
しかし、一方でいざテクニックを覚えようとしても、何から覚えていけばいいかとっかかりがわからず、結局自身の知っている範囲でのショートカットやテクニックのみを利用してしまうといったことはないでしょうか？
このセッションでは日常の業務で役に立ち、かつ手をつけやすい PhpStorm のテクニックを段階ごとに解説し、徐々に PhpStorm エキスパートに近づく手助けをすることを目的とします。

$_GET["page"]、$_POST["name"]、$_SERVER ... PHP を初めて触った日、これらの変数を扱いませんでしたか？
これらの "スーパーグローバル" と呼ばれる変数は、初学時にこそ利用しますが、フレームワークを使い始めるとすぐに利用しなくなり、すでに忘れてしまった人も多いのではないでしょうか。
基本的にフレームワークの仕組みを使えば、これらの変数を利用する機会はない上に、中には設計上、セキュリティ上利用すべきでないとされている変数も含まれているため、PHP を扱っていてもあまり正面からスーパーグローバル変数を理解する機会は少ないと思います。
本セッションでは、PHP 初学者を対象に、スーパーグローバル変数をおさらいし、何気なく使わなくなったこれらの変数がなんだったのか、意外と理解していない使わなくなった理由について考えることで、PHP 初学者以降のスーパーグローバル変数との付き合い方を紹介します。

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

では、「どういうことが出来るのか」はご存知でしょうか。
「あの便利なComopserが、更に便利になっちゃうんですか？！」とワックワクな妄想をしてみたい・・・そのためには、まず「どういう事ができるのかな？」を知る必要があります。

知ることが全ての始まりです。
もしかしたら、あなたの仕事に革命を起こすような素晴らしい可能性が眠っているかもしれません。
(もちろん、「not for me!!!」と叫ぶだけの結果に終わる可能性もあります)

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

PHPウェブアプリケーションにおいて、データベースは不可欠な存在といっても過言ではありません。テーブル設計の方法論や、各種 RDBMS ごとの特性、チューニング方法の理解などを通して、データベースについて学んだ方も多いと思います。

本トークでは、ふと「PHPでデータベースを作ってみたら、もう少しデータベースと仲良くなれるのではないか？」と思ってしまった私が、データベースを作成していく過程で得られた知見について、発表します。

• データベースの基本構造
• なぜMySQLはB+木を使うのか
• インデックスとは何か
• 構造から考えるチューニングのツボ