トーク

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

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

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

新規のプロジェクトが始動して開発を始めるとなったら、まず何を行うでしょうか？
GitHubにリポジトリを用意して、Laravelの環境を用意して、すぐに各チケットの本開発に入るのでしょうか？

新規プロジェクトは最初は純粋無垢の綺麗な状態ですが、雑に開発を始めてしまうと、ある瞬間に何かしらのやばい匂いが漂っていることに気づくことがあります。
スピードだけでなく開発のしやすさなども考慮しつつ、レガシープロジェクトにならないように意気揚々と始めたにも関わらず、なんかおかしいぞ？となる瞬間があります。
そこで、本セッションでは、新規プロジェクトにおいて、少しでも長いスパンで本開発をスムーズに進めるためにまず最初にやるべきことを紹介します。

特に、以下のような内容を話します。
・コーディング規約チェック機構、静的解析、テストなどの用意
・CI/CD
・Xdebug
・サンプル構築
・チーム内コミュニケーション
・READMEやドキュメントの整備

Discord Channel: #track4-2-b-env-setting

PHP-FPM（FastCGI Process Manager）の設定項目を「なんとなく」「デフォルトのまま」にしていませんか？
不適切な設定は充分なパフォーマンスが発揮できないばかりか、障害の原因にもなりかねません。
本発表では PHP-FPM の子プロセス制御方法と設定項目の意味、適切な設定値の判断方法について説明します。

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

CI(継続的インテグレーション)してますか？

このセッションでは、CircleCIを使ったCIの構築事例と、テスト高速化やデプロイフローの効率化などのさまざまな工夫を紹介します。
「CIやってみようかな」「うちでもテスト高速化できそう」「え？こんな機能あったの？」といった学びがあれば幸いです。

工夫の一例

• テスト高速化・並列化・もっと並列化
• 確認ダイアログによる人力最終チェック
• PR自動マージによるマージ忘れ防止
• Gitのタグを見てフローを分岐

スタッフに興味あるけど「スタッフってつよつよエンジニアばかりなんじゃないの？」とか「自分なんかにできるのか？」なんて不安を感じて応募を躊躇ってしまっていませんか？
いつもお世話になるばかりだった私が、当日スタッフに応募しようと思った動機と、実際にやってみてどうだったかという話をしたいと思います。
そして「次回は応募してみようかな」と思った方が一人でもいたら嬉しいです。

皆さん、PHPのDockerイメージは使ってますか？

開発手法は人や組織によって様々ですが、ローカルでの環境構築や本番環境へのデプロイにDockerイメージを使うことは一般化しつつあります。ですが、普段使っているイメージの中身をきちんと把握していると言い切れる人は意外といないかもしれません。そこで今回は「PHPのDockerイメージの深堀り」をテーマにお話をしたいと考えました。

・「何のために使ってるか分かってないけど、依存関係の都合でとりあえず入れてる。」
・「イメージのサイズが大きくなってきたから軽量化をしたいけど、パッケージの役割がよく分からなくて触りにくい。」

このセッションでは、自信と確信をもってDockerイメージの運用をしたい方へ向けた掘り下げを話していきたいと思います。細かい構成は決まっていませんが、軽量化の話を交えた構成にするつもりです。

※特定のフレームワークを深堀りする話はしませんが、リアルなDockerイメージを作るためにLaravelやCakePHPを使用する可能性はあります。

Discord Channel: #track4-2-a-php-docker

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

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

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

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

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

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

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

トーク概要

コンピュータシステムの理論と実装という本を読んでおり，アセンブラの実装をすることになったので，アセンブラとはどのような機能を提供し，どのようにして実装をするのかという話をします．

コンピュータのソフトウェア階層の中で，最も基礎となるモジュールであるアセンブラを実装することによって，アセンブリ言語で書かれているプログラムがどのようにしてバイナリで書かれたプログラムに変換されるのか，その仕組みを広く浅く話したいと思っています．

トーク対象・分野

PHPでモノを作るのがお好きな方，なぜか知らないけれどPHPでモノを作ることにロマンを感じる方，低レイヤーがお好きな方

その他

大きなカンファレンスなどに登壇するのは初めてです．

普段開発しているコードベースでは PHPStan で静的解析をしているものの Lev.1 に留まっており、レベル上げをしようとすると大量のファイルがあって膨大な数のエラーが出てしまい手付かずの状態でした。静的解析が弱い分、ユニットテストや手動テストを主にして検証を行っていますが、手動テストの終盤で型エラーが起きてやり直しになるなど、非効率なことが起きていました。

その状況を改善すべく、モジュール毎に静的解析レベルを設定することで独立したメンテナンスを可能にし、比較的新しいモジュールからレベル上げをしていきました。
本セッションではその取り組みやつまずいたポイント等について紹介し、これから静的解析を強化していく方の参考になれば幸いです。

・解析対象と実行方法の整理
・レベル別静的解析の恩恵
・Laravel IDE Helper の問題点とその対応
・レベルを上げてからのコードの書き味

Discord Channel: #track2-5-b-php-static-analysis-max

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

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

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

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

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

At the recent years, I used a lot PHP to develop my web crawlers and save my life to make some duplicated works automated.
I also research them and write a book (it's written in Mandarin). And the book link is available here: https://www.books.com.tw/products/0010882656
This book tile translates to English is: PHP Web Crawler Development:From beginner to advanced web crawler technique guides.

In this session, I will present following topics:

• The motivation about writing this book.
• The guide about web crawler developments and sections introduction
  • Basic HTTP fundamentals and the tips for inspect HTTP packets and requests via web browser.
  • The PHP web crawler environment building demonstration.
  • Using the advanced web crawling techniques. Such as headless Chrome web browser.
  • Some Labs and live demonstration about developing crawler.
• The feedback and experiences about publishing this book.
• Extended references and other advanced crawling tips that not included in books.
  • Inspecting HTTP packets and requests via non-web browser.
  • Advanced extract/decode CAPTCHA codes.

Discord Channel: #track4-4-b-php-web-crawlers
Joind.in: https://joind.in/event/php-conference-japan-2021/best-practices-for-using-php-to-develop-web-crawlers

トーク概要
PHPそのものにバグがあるということがあります。仕様が変更されたために起こったバグだったり、PHPほどの歴史があるオープンソースソフトウェアだと皆に知られないまま十何年も潜ってしまったバグもあったりしたりします。

バグ報告を行おうとすると、PHPの側がおかしいのか、自分のPHPコードがおかしいのかで切り分けないといけませんし、仮にPHPそのもののバグだとすると、PHPのソースコードの莫大さと、PHPや使用しているライブラリの歴史の厚み、マニュアルにない仕様の変更、頻繁かつ大規模なリファクタリングなどが壁になりがちで意外と大変です。

私が間違っているのか、PHPが間違っているのか。大体は前者です（そして、そうあってほしいのです）が、後者だったときの切り分けの仕方を考えてみませんか。

トーク対象
PHPのバグを見つけてみたい人や、PHPのみならず規模が大きいソフトウェアのバグとどう見つければいいかの参考になれれば嬉しいです。

Discord Channel: #track3-2-b-php-src-bug

小学校でプログラミング教育が必修化される中、「Scrach」のような
ビジュアルプログラミングは注目されています

そんな中、LOVOT（https://groove-x.com/）と呼ばれる
『役に立たない、でも愛着がある” 新しい家庭用ロボット』がコンセプトの
ロボットに、「LOVOT STUDY ビジュアルプログラミング」という
ブラウザを用いてビジュアルプログラミングし、LOVOTを操る仕組みが提供されています

"ビジュアルプログラミング"でできることは、PHPでもできる！ことを
実証するために、
本来、ビジュアルプログラミングで操作するLOVOTを
直接PHPのプログラムから操作してみました(非公式)

まずは、ビジュアルプログラミングを解析する過程、そして
解析内容を元にPHP（Ampを用いて）で再実装する過程をお話しします

Let's PHP programming！

小学校でプログラミング教育が必修化される中、「Scrach」のような
ビジュアルプログラミングは注目されています

そんな中、LOVOT（https://groove-x.com/）と呼ばれる
『役に立たない、でも愛着がある” 新しい家庭用ロボット』がコンセプトの
ロボットに、「LOVOT STUDY ビジュアルプログラミング」という
ブラウザを用いてビジュアルプログラミングし、LOVOTを操る仕組みが提供されています

"ビジュアルプログラミング"でできることは、PHPでもできる！ことを
実証するために、
本来、ビジュアルプログラミングで操作するLOVOTを
直接PHPのプログラムから操作してみました(非公式)

まずは、ビジュアルプログラミングを解析する過程、そして
解析内容を元にPHP（Ampを用いて）で再実装する過程をお話しします

Let's PHP programming！

Discord Channel: #track3-5-a-php-robot

【トーク対象】
・AWS RDS を利用されている方

【分野】
運用、データベース

【トークの概要】
AWSのRDSでMySQLを利用されている方は比較的多くいらっしゃると思います。
MySQL5.6が2021年2月にExtended Supportが終了したのをご存知でしょうか。
Extended Support終了に伴い、RDSのMySQLも5.6が廃止されます（2021年8月に廃止でしたが、どうも難航しているようで2022年2月まで延期されました）。

RDSはマネージド環境であるため一見管理不要なように思いがちですが、メジャーバージョンアップなどでは停止を伴うメンテナンスが必要になります。RDSを利用するwebアプリケーションによりますが、ダウンタイムの発生で大きな影響が発生しうるので計画的に対応する必要があります。

本セッションでは、実際のMySQL5.5から5.6、5.6から5.7へのアップグレード対応の事例を紹介します。マネージド環境でもダウンタイムが発生しうること、ダウンタイムを0もしくはできる限り短くしなければいけない場合の対応方法についてお話します。マネージド環境であってもメンテナンスを続けていかなければいけないことをお伝えできれば良いなと思います。

【トーク対象】
・LaravelのSessionについて知りたい
・障害発生時の原因特定から対策までの流れが聞きたい

【分野】
運用、データベース

【トークの概要】
webアプリケーションでCookieを利用したSession管理を行うことが多いと思います。
最近のフレームワークはSessionをとても簡単に活用できるためその維持管理について特に考えないことが多いです。

Laravelで構築したwebアプリケーションで、急激な性能劣化が発生して原因の特定と対策をすぐに行わなければいけない状況が発生しました。結果的にLaravelのSession設定を変更することで劇的にパフォーマンスが改善しました。

本セッションでは、なぜSessionが原因で性能が劣化したのか、また改善した理由について、経緯を踏まえてお話します。PHP/Laravelでのセッションの大まかな仕組み、性能劣化の要因、対策方法について説明します。

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

1番最初にOSSにPRを出した時に、皆さんは緊張されませんでしたか？僕はしました笑
PRを出すのはこの方法であっているのだろうか、的外れなPRではないだろうか…などなど。
このセッションでは、OSSにPR出すのにあたってまずは翻訳から参加することで心理的なハードルが下がったり、翻訳も案外勉強になってしまうことを、翻訳のtipsと共にお話しします。