自分は2019年2月に個人事業主となって以来、３つの副業案件を経験しました。
本LTでは自身の体験をもとに以下について話をできればと思います。

• 副業を始めるための準備として何が必要か
• 副業案件の契約締結にあたっての重要事項
• 副業を継続していく秘訣と個人事業の将来

主力言語としてPHPを掲げ、それゆえに思い通りにいかないこともありましたが、
それなりに自身を広げ、Re:born できることを示すことができれば嬉しいです。

PHPから派生し独自進化を遂げたHackを使ったアプリケーション開発では、
PHPと異なり、静的型付け言語のような堅実なアプリケーション開発をサポートする強力な機能が多く用意されています。
本セッションではそれらを使い、アプリケーションアーキテクチャ設計と、
Hackならではの実装コードに落とし込んでいくヒントを紹介します。

何らかの理由によって「既存のクラスやAPIの使い方が変更された、それに対応しないといけない！」という場面が、
しばしば開発の現場には発生します。
その時に、なるべく「人間の目と手で作業する」という負担は避けたい・・面倒くさいな・・と思うのが人の心情ではないでしょうか。

https://github.com/rectorphp/rector は、既存のPHPコードのリファクタリングやアップグレードを自動実行するツールです。
こいつを上手く使えれば、あの退屈で機械的な作業を真の意味で「機械の作業」にする夢が叶うかも知れません！！

本セッションでは、Rectorについて紹介し、具体的に活用するための方法を話したいと思います。

おしながき

• Rectorってなに？
• どういう仕組で動いてるの？
• 具体的にどうやって使われてるの？ 〜CakePHP4の アップグレードコマンドを例に〜
• 独自ルールを作ってみる

アプリケーションのモニタリングしていますか？
デプロイした後のパフォーマンスチェックしてますか？
障害が起きてから監視ツールを眺めていませんか？

ライセンス形態が大きく変わり、監視プラットフォームとして使いやすくなったNewRelicを利用して
NewRelicはAPMの印象が非常に強いですが多くのソリューションが存在します。
それらを少しずつ使って自分達のオブザーバビリティプラットフォームを作り、プロアクティブにモニタリングしていきましょう。
APMに始まりNewRelic logsによるlog収集、Browserによるフロントエンドパフォーマンス監視、InfrastructureによるAWS監視、Syntheticsによる一歩進んだ外形監視。
そしてそれらの監視をダッシュボードにまとめていく、といったところまでをお伝えします。

概要

「PHPで何かを作ろう」と思った時に「今風のコードを書くのに必要なもの」を考えてみました。
新しいプロジェクトをスタートする時に、「こういうのがあったら良いのでは」という案を
みなさんと共有して、知見を育みたいです。

過去に個人ブログにも投稿した内容をベースに、「狙い」や「考えたこと」を紹介します。
PHPお手軽スタートキットを作った - 大好き！にちようび

イントロ

人は、熱しやすく冷めやすい生き物です。
例えば、あなたが「あ！ちょっとこういうライブラリを作ってみよう！！」と思ったとします。
その時に、ゼロから「必要なもの」を考えますか？
「まずはphpunit.xmlを用意して、あと静的解析も入れたい。PHPStanのルールってどうやって書くんだっけ？CIも入れなきゃ・・あ〜GitHub actionsのworkflowの書き方がさぁ・・・」
そんな事に煩わされている間に、どんどんと「腰が重く」なり、「着手が遅れ」、そして「熱が冷め」てしまう。

そんな経験はありませんか？
私は、過去に何度も「README.mdだけコミットしてある空レポジトリ」を消したことがあります。

やったこと

この「腰の重さ」を支えて、「浮かんだアイディアを試すためのコードを書き始める」までを軽減したいと思ったのです。
そこで、「このくらいの要素が揃っていれば、気持ちよくPHPアプリケーションの開発をスタートできるだろう」という、
「ぼくのかんがえた さいきょうの いまっぽい PHPのツールたち」を揃えてみることにしました。

お話したいこと

まずは、「PHPアプリケーションのボイラープレート」に含めた内容を紹介します。
この内容をモチーフにして、「今日におけるPHPの開発体験を高く保つためには」というテーマに触れられたらと思います。

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

■ 想定する聴講者

• PHP スクリプトの行レベル / VM 命令レベルでの性能や測定方法が気になる人
• 今後の PHP の性能の伸びしろに思いを馳せたい人
• しょうもないマイクロベンチマークが好きな人

■ お話しないこと

• 明日から業務に使える役立つ知識

「重い処理を早くしたい」といえば、処理の非同期化です。
「PHPで非同期」というと、「Swooleだ」「pcntlを使って」といった声が聞こえて来そうです。
あるいは、(HTTP)リクエストについてならば、「guzzleのasyncで」「curl_multiで」と耳にします。

さて、「MySQL 改良版拡張モジュール MySQLi」を皆さんは活用できていますか？
昨今の一般的なPHP環境であれば、こいつを使えば「重いSQL処理をMySQLにパラレルで投げておく」が可能になるわけです！！

本セッションでは、今一度、改めて「MySQLiを使って非同期処理を行うには」という方法について学んでみたいと思います。
(そんなに高度ではない内容です)

想定する聴講者

• あんまり mysqli::pollやmysqli::reap_async_query という文字列にピンとこない方
• 「何が何でもレイテンシを下げたいんだ、しかし必要なSELECTが多すぎて・・・」と悩んだ事がある方

おしながき(仮)

• PHPで書いたコードでの「非同期処理」の制御の仕方
• 「MYSQLI_ASYNC」モードを指定した時の動作
• 実用性のあるコードで利用可能にする

Composer の普及により、PHP における Web アプリケーション開発において外部ライブラリやフレームワークを活用にするのは一般的になりました。みなさんもアプリケーションで要求される機能要件、非機能要件の観点からライブラリを選定して利用しているでしょう。

今抱える課題を解決するため、欲しい機能を実装するために導入したライブラリですが、アプリケーションに組み込むということは、これからアプリケーションが動き続ける長い道のりを共に過ごすということになります。

導入した当初はその時点における安定したバージョンや最新バージョンであったとしても、時間の経過と共にライブラリはバージョンアップを続けていきます。それに逐次追随できれば良いのですが、いつもそれが簡単にできるわけではありません。特にメジャーバージョンアップにより、後方互換性を失う変更が入った際は容易ではありません。そのライブラリを利用している箇所全てが影響を受けるので、単に composer update すれば済むという話ではありません。

このようにライブラリの導入は容易ですが、その後の長い運用を想定してアプリケーションにどのように組み込むかという視点が必要となります。

本セッションでは、下記のようなトピックを交えて、アプリケーションにおけるライブラリの活用戦略を考えていきます。

• ライブラリへの依存
• PSR に準拠したライブラリなら良いのか？
• 要求をインターフェイスにする
• フルスタックフレームワークとオリジナルフレームワーク

待望の PHP8 が出ましたね！
パッケージマネージャーで PHP をインストールすることが多い昨今、ビルドって実際にどうやるんだろう？と疑問に思っている方も多数いらっしゃると思います。
敷居が高そう、難しそう、そう思っている方もいらっしゃると思います。しかし本当は PHP そのもののビルドはそんなに難しくありません。
ということでトークの時間を目一杯使って PHP8 のビルドをオーディエンスの皆様と一緒にライブ形式でやってみたいと思います。
本トークで、ビルドをどうやるのか感覚を掴んでいただき、ぜひ様々なシーンでご活用できるようになっていただければと思います。

最近やっとこさ本番環境もDockerで動かすようにできたのですが、そこまでの道のりは長いものでした。既存のアプリケーションをそのままDockerにのせてえいやと本番で動かせるケースは少ないと思います。アプリケーションを改修したりインフラの構成を変更したり・・・トップダウンで(本番環境から徐々に)進めようとすると手元の環境はなかなか改善されません。

でもまずは手元の環境を新しくしたい・・・手元の環境だけでもモダンな感じにしたい・・・でも最初からGithubやAWSにお金はかけられない・・・みたいな状況だったとしても打つ手はあります！

このLTではわたしが開発環境カイゼンをはじめた際、最初に取り組んだことをご紹介します。

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

PHPWebアプリケーションを構成する要素として、
パフォーマンスを向上させるポイントはどこにあるのでしょうか。

今回はPHPWebアプリケーションを速くするポイントを
PHPに限らず幅広い視点で見直してみようと思います。

OS、Webサーバー、PHP、RDBMS等の見直すべき要素に関して触れ、
愚直に改善を行うべき場所を再考し、
堅実にパフォーマンスを改善する方法をお話しようと思います。

■想定する聴講者
　- PHPWebアプリケーションのパフォーマンスに興味がある方
　- PHPのインフラを整備するエンジニア

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

PHP8は速い、速いはずなんだ！

JITを中心にPHP8はパフォーマンスへの期待が高まっています。

今回は3分一本勝負でPHP8がいかに速いかをひたすら主張してみようと思います。

私達PHPerの夢を載せて、PHP8と共に3分間駆け抜けようと思います。

■想定する聴講者
　- PHP8のパフォーマンスに興味がある方
　- PHP8のベンチマークに興味のある方

■お話しないこと
　- パフォーマンス以外の話
　- 話す必要がないと感じたこまけぇ理論

ステートレスなHTTPをステートフルに変えてくれる仕組みがセッションです。ユーザのログイン、リダイレクト後のエラーメッセージの表示、CSRF対策等、現代のウェブアプリケーションで多用されているセッションですが、セッションがどのように動いているかと聞かれた時に正しく答えられますか？
初心者に近いPHPerがセッションを多用すると、中堅クラスのエンジニアから「セッションは危ないから多用しないように」とアドバイスされることも多いと思いますが、それは何故でしょうか？

本トークでは、ウェブアプリケーションにおけるセッションについて、その正体を分かりやすく解説します。また、セッションの正体を知ることで、ウェブアプリケーションのアーキテクチャーに対してセッションが及ぼす影響についても解説します。セッションにまつわるアレコレを解説することで、初心者とベテランエンジニアの間に存在する知識と経験の差を少しでも埋めることが狙いです。

このトークでお話すること

• セッションの仕組み
• Laravelにおいて無意識に利用されているセッションの例
• Laravelが独自のセッション管理を行う理由
• セッションが本番アプリのアーキテクチャに与える影響

今でこそPHPはRubyと比較されることは少なくなりましたが、PHP5の時代はよくRubyもしくはRuby on Railsと比較され、そしてときにディスられもしました。

時は流れPHPはバージョン7を経てバージョン8へと進化し、Webアプリケーションフレームワークとして洗練されたLaravelも台頭してきました。今ではプログラミング言語人気ランキングでPHPはRubyより高い位置にランクインしています(*1)。

本発表は改めてPHPとRubyを比較することで見えてくる＜PHPらしさ＞に着目して、＜PHPの良さ＞の再発見をしたいと考えています。

本発表の想定オーディエンスは下記の通りです。
・Rubyに興味があるPHPer
・Rubyをちょっと書いたことのあるPHPer
・元・RubyistなPHPer
・元・PHPerなRubyist

*1 TIOBE Index https://www.tiobe.com/tiobe-index/

※発表者はPHPもRubyも好きなエンジニアです。発表の目的は、言語に優劣をつけることではなく、あくまでも言語比較・Webアプリケーションフレームワーク比較を通してPHPの良さを発見することを目的としています

PHPではIDEとして普及しているPhpStormのほか、静的解析ツールを活用することで実行なしでコードの問題点を検出できます。

さらには、Phan, PHPStan, Psalmなどの静的解析ツールが提供するタグや機能をPHPが本来持っている以上の能力を持った型を記述できます。
今回のトークではPHPが持つ基礎的な型と静的解析ツールが独自に提供する型、そして、これらだけでは解決できない型付けの問題についても紹介します。

アプリケーションコードや運用保守などクエリを書く場面は様々ありますが、皆さんはクエリを書くときにどんなことを意識していますか？
「えーっと、まずはSELECT句から書いて…」
簡単なクエリを書く分にはそれでも良いですが、複雑なクエリを書くようになったらどうでしょうか？

当LTではSQL実行順序に焦点を置いて、複雑なクエリを書くためのアプローチについて話していきます。

みなさんは億単位のレコードが存在しているMySQLテーブルをみたことがありますでしょうか？
もし、そのうち大半のレコードが不具合によって生み出されたものだとしたら、きっとDELETE文を実行したくなると思います。
でも待ってください。ただDELTE文を実行しようとしても、トランザクションは非常に大きくなり、ディスクIOやテーブルロックなどが原因となって、性能問題が生じてしまうでしょう。
このセッションでは安全に億単位の不要レコードを削除する方法をお話しします。

• 長らく「お互い6は黒歴史、いつまでも5.x系」だったMySQLとPHP

  • MySQL 5.7「そうか…お前は7に行くんだな」
  • PHP7「お別れだな」
  • 5年くらいの時を経て、ふたり(?)は再び8で巡り合う…！

• PHP成分はありません。MySQL 8.0のことを紹介します

  • 5.7から8.0になって増えた機能、変わったもの
  • CTE/Window関数、知っていれば使えるかも知れない新しいクエリー
  • TCP over SSL推しの新しい認証
  • ついにいなくなったクエリーキャッシュ
  • その他増えたり減ったりした機能
  • 継続的リリースモデル
  • 何故か3カ月に一度、新しい機能が増える
  • GA(General Availability)とは何だったのか

現在、社内で有志を集めて輪読会を開催しています。
週に1回の開催で既に第30回にもなり、現在課題本として扱っている書籍で4冊目となります。
まだまだ少ない開催数ではありますが、順調に続けられてきています。
輪読会や勉強会を開催したいけど運営が面倒で続かないなどの経験がある方もいるのではないでしょうか？
本LTでは、3分間で、輪読会をやる理由・やり方・続けるコツなどをご紹介します。

輪読会や勉強会を開催したいけどなかなか続かない、開催を検討している、どんな本を選んでるのか気になる、といった方々に聴いていただきたいと思っています。

弊サービスは今年で14年目となりました。
そんなサービスをずっと支えてきたオンプレのデータベースOracle、これをAWSのPostgreSQLに移行することになりました。
これは、弊社全体としてクラウド移行が推進されるなかでの、私たちチームのクラウド移行プロジェクトの第一弾です。
データベースはアプリケーションよりも寿命が長いと言いますが、積年のデータの詰まったデータベース移行はサービスの中心にあるためいきなりラスボス級の難易度です。
本セッションでは、オンプレのOracleからAWSのPostgreSQLへの移行に伴って行った意思決定や方針・やり方をご紹介します。

主に、以下の内容をお話します。
・弊サービスの構成と移行方針
・なぜラスボス級のDB移行を先に行うことを決めたのか
・移行に役立つAWSサービスのDMSとSCTの軽い紹介
・アプリケーション(PHP)の修正の方針
・移行に伴うあらゆる罠

以下の内容についてはお話しない予定です。
・AWSサービスの詳細な説明
・Oracleの詳細な説明
・PostgreSQLの詳細な説明

移行を検討している、移行の進め方が気になる、どんな罠があるのか知りたい、といった方々に聴いていただきたいと思っています。