トーク

このセッションでは求人数1位になったPHPの状況と、いよいよ本番試験開始となった徳丸実務試験とPHP8上級試験の模擬問題解説を行います。WordPressの原理原則を問うKUSANAGI for WordPress認定試験の紹介も行います。

Discord Channel: #track1-6-b-php技術者認定機構

OpenAPIにはリクエストやレスポンスだけでなく、求める型や正規表現も記述して利用することができます。コードの自動生成についても盛んに行われていることもあり、最近のプロジェクトでは採用されることが多いのではないでしょうか？
とはいえ、OpenAPIを自分たちで書かなければいけない場合はめんどくさいと思います。
そこで、このセッションではLaravelからOpenAPI仕様書を自動生成する方法を紹介します。
また、生成したOpenAPI仕様書を閲覧用として利用するだけではなく、LaravelのE2Eテストやバリデーションに生かす方法についても話します。

このセッションで話す内容

• LaravelでOpenAPIを半自動生成する
• LaravelのE2EテストのアサーションをOpenAPIに沿った形で行う
• LaravelのFormRequestにOpenAPIを使う
• (予定)今回の内容を業務で利用してみた感想

想定するレベル感・技術的な要素

• OpenAPIやSwaggerを知っている
• Laravelを使ったことがある

Discord Channel: #track1-7-a-yumemi

2019年にGaroon（ガルーン）のレガシーさに立ち向かい改善が行えるようになってきたとお話ししてから2年が経ちました。
https://speakerdeck.com/oogfranz/gai-shan-shi-bai-sitexue-bu-regasipurodakutonili-tixiang-kautimuzuo-ri
このセッションではこの2年間で実施してきた改善内容と、持続的に活動をしていくためにどのようにチームのプロセスを変えていったかについてお話しします。

この2年間、開発チームはバックエンドのController層を改良したり、フロントエンドをES5からTypeScriptに移行するなど、メンバー全員で色々な改善を実施してきました。
もちろん改善活動だけでなく、新機能開発やそれ以前から行っていたPHPのアップグレードなどGaroonを継続して提供していくための活動もしています。
なので、Garoonに必要なタスクをしながらも、改善もできるようになりました。万歳！

...とはなかなかなりません。
開発されてから19年目を迎えたこの巨大な製品には、まだまだ多くの負債が着手されないままに残されています。
また、新機能を開発しながらも多くの負債に立ち向かう中で、どの負債から優先的に対応するのかや人的リソースをどう割り振るかなど、チームとして改善を試みることの難しさに直面しました。
プロダクトのレガシーさに立ち向かえる環境作りはできましたが、それだけではレガシーさに立ち向かうのは難しいのだという当然のことに改めて気付かされました。
そんな中で、より効率的かつ持続的にプロダクトを改善していくために必要だと気づいて取り組んだ課題が、チームのプロセスを見直すことです。
これをきっかけに、問題意識の言語化や各種活動の振り返りが進み、いまチームは「Garoonを開発者にとって魅力的なプロダクトにする」ことを新しい目的として、以前よりさらにワクワクしながら活動し始めています。

そんなサイボウズGaroon開発チームの経験を是非お聞きください。

Discord Channel: #track1-6-a-cybozu

ユーザからのお問い合わせに対して適切な回答を行うことは、様々なサービスを提供する上でとても重要です。弊社ではその中でも技術的なお問い合わせについて、Slack上で問い合わせ担当エンジニアへ調査を依頼する業務フローが存在します。現在、問い合わせ担当エンジニアは当番性であり、担当領域以外の問い合わせについても対応しています。この業務フローに関して、新しいお問い合せのうち、一部は過去に対応したお問い合わせと類似したものや一致するものが存在し、回答の参考になることがあります。
本セッションでは、新しいお問い合わせについて、過去のお問い合わせから類似するものをAmazon Elasticsearch Serviceを使用して自動で抽出し、同時にKibela Web APIを使用して関連するドキュメントを検索した上で、Slackのスレッドに投稿するシステムについて導入した話を紹介します。

Discord Channel: #track1-a-base

Hameeでは"ネクストエンジン"というプロダクトをPHPを使って開発・運用をしています。

ネクストエンジンは13年の開発・運用を重ねて成長してきた一方でたくさんの課題も抱えており、その課題を解決するため日々改善活動を行っています。今回は監視の観点から弊社アプリケーションエンジニアとSREエンジニアの二名が現場から生の声をお届けします。

• どんな問題があり監視を行っているのか
• どのような監視を行って改善しているのか
• アプリケーションエンジニアとSREエンジニアでどう連携を行っているか

対象

• まだ監視していない人
• 監視しているけど、うまく運用できていない人
• 13年物のプロダクト開発・運用に興味がある人

Twitter:
日野陽平 (https://twitter.com/money166)
大嶋淳司 (https://twitter.com/atsusics)

Discord Channel: #track1-1-b-hamee

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

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

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

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

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

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

PHPコーダーの皆さん!型、付けてますか?

PHPStanやPhan、psalmを利用することで、PHPでも実際に実行する前に型エラーを検出することができる事は既にご存知でしょう!(知らなくてもこのセッションを聞けばOKです)

静的解析のライブラリを活用することで、

• int|nullを返却する関数のnullハンドリングを忘れていたり
• '1' === 1といった数字文字列の取りあつかいの間違えを見つけたり
• 存在しない可能性のある配列の中身へのアクセスを事前に検知したり
  することができます

特に、PHP8からは、存在しない配列の中身へのアクセスがWarningからErrorへ変更されており、環境によってはPHP7からのアップデートでアプリケーションが動かなくなる原因の一つである一方、Union型のサポートなど、言語としての型サポートも整っていく傾向があり、アップデート作業の一環としても強力なツールとなります。

既存のPHPプロジェクトに静的解析ツールを導入する際に問題になるのが、

• エラーが多く出すぎる
• アプリケーション内で、文字列でクラス名を扱かっているのでクラスが静的解析で追えない
• 値域を厳密に制限する関数や返却する型が動的に変わる関数では、PHPdocのtypehintを利用した静的解析では、動的な型付けに対応できない
  場面が多くあります。

このセッションでは、PHPStanを用いた型解析について説明した後に、

• ~コミット差分によるエラー検出をし、変更箇所に起因するエラー箇所をciで警告するようにした方法(github actions/gitlab-cilですぐに使えます!)~
• PHPStanのオリジナル拡張を作って、PHPStanデフォルトの機能で手が届かなかった点を改善する方法(実際にセッション中に拡張を作ります!)
  について話します

Discord Channel: #track2-5-a-php-static-analysis-2021

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

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

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

紹介するお話

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

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

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

この課題を選んだ背景

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

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

速いは正義、アプリケーションは速くあるべきです。

なんとなくやってるパフォーマンスチューニング、
チューニングを行うとPHPWebアプリケーションはなぜ速くなるのでしょうか。

意識的に作った遅いアプリケーションを使い
OS、Webサーバー、PHP、RDBMSが遅い原因を知ることで、
遅くなった原因を一つ一つ分解して解説します。

パフォーマンスチューニングを行うに当たり必要な基礎理論を見直し、
なぜ遅いのかを知り、どうすれば速くなるのかを知ることで、
具体的なチューニングをなんとなくではなく、意志を持って選択出来るようにしましょう。

■想定する聴講者
　- PHPWebアプリケーションのパフォーマンスに興味がある方
　- PHPのインフラを整備するエンジニア
　- なんとなくオススメのチューニング設定を貼り付けてる方

■お話しないこと
　- パフォーマンス以外の話
　- アプリケーションコードによる改善
　- 劇的なパフォーマンス改善策

Discord Channel: track2-3-a-php-performance

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

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

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

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

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

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

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

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

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

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

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

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

私はこの数ヶ月、趣味プロジェクトとして、1990年代にアーケードゲームやハイエンドパソコンで輝きを放ったYAMAHAのFM音源チップ、YM2151を制御するためのハードウェアとソフトウェアの開発をしています。

こう言うと難しく聞こえるかもしれませんが、実はハードウェアの世界にも私たちソフトウェアエンジニアが「API」や「プロトコル」と呼びそうな決まりがあり、その決まりに従って音源チップに命令を与えることで音を鳴らすことができるのです。

このトークでは私が開発しているYM2151制御ハードウェア・ソフトウェアを題材に、コンピュータシステムの周辺ハードウェアがどの様に制御されるか、そしてその制御をソフトウェア的にどの様にするかを解説します。もちろん制御ソフトウェアはPHPで書いていますのでPHPerのみなさんであればスッと読めると思います。

このトークを通じてコンピュータシステムの動作について興味を持っていただく方が増えることを期待しています！

Discord Chanenel: #track3-5-b-php-hardware

皆さん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ふりかえりをどのようにやっているのかを共有させていただきたいと思っています。

バージョン 8 にしてとうとう僕らの PHP にも JIT がやってきました！
が、PHP 8 の JIT は生まれたてで、同じ 8 でも JavaScript の V8 にはまだまだ速度的な面で追いつかない部分があります。
PHP と JavaScript のそれぞれについて、おおむね同等の処理を行うマイクロベンチマークのコードを用い、プロファイルをとりながらああだこうだ言いつつ速さの特性差や PHP の現状の限界、得意な点や不得意な点を探っていきます。

■ 想定する聴講者
・典型的な Web アプリケーションは主に I/O バウンドとかそういう現実の話は脇に置いておいて、PHP スクリプトの性能や測定方法が気になる人
・今後の PHP の性能の伸びしろに思いを馳せたい人
・しょうもないマイクロベンチマークが好きな人

■ お話しないこと
・明日から業務に使える役立つ知識

Discord Channel: #track2-3-b-php8-vs-v8

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

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

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

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

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

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

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

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

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

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

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