トーク

2023年4月時点で、CakePHPは5.0βの開発が進行中です。
およそ3年ぶりのメジャーバージョンアップとなり、PHP7へのサポートを終了する最初のバージョンとなります。
コードネームはChiffon(シフォンケーキ)と言います。

まだまだ機能のスコープは安定しませんが、どんな変化が予想されて、使い勝手はどう変わるのでしょうか？
このトークでは、カンファレンス当日までのなるべく最新の情報を取り込んで、開発状況・個人的な所感や予想について共有します。

話すこと

• CakePHPの4.3辺りからの「どういう変化が起きているか」のおさらい
• CakePHP5.0で計画されている変更点
• それらを総じて、「このFWはどういう方向に向かおうとしているのか」の所感

テスト書いてますかー！と聞けば、書いてますよー！と元気に答えてくれる人って多くなっていそうですよね。
では、得意ですかー！とか、他人に教えられますかー！とかって聞くと・・？難色を示す人も多いのではないでしょうか。

「テストを勘で書いてきたし、書けるようになってきたけど、そろそろ品質とか理論とかを学びたい」という人に向けたトークをします。
ただし、これは非常に深く広大な話題だと思うのですよね。
そこで、単体テストにフォーカスを絞って、「考え方を身に着けたり、引き出しを増やすために役立ちそうな情報はないのか？」に応える「手引き」となるようなトークをします。
どういう課題を持っているか・どういう知識を身に着けたいのかというケース別に、処方箋となりそうないくつかの書籍や情報リソースを紹介します。

想定対象者

• 「普段の仕事では単体テストを書いている」くらいのレベルにはあるけど、自分の書くテストに自信がない人
• 「テスト中級者」よりも手前のレベル感だなぁ、と感じている人
  • 「全く書いたことがない」という人はスコープから外れます！

話すこと

• テストについての(一般化された)知識、理論を学ぶための情報
  • 主に単体テスト
• 日頃から「テストをスラスラと書けるようにする」ための学び方、鍛え方

話さないこと

• PHPUnitなど、特定のテスティングフレームワークの利用者練度を高めるためのtips
• テストの「動かし方」やテスティングフレームワークの内部構造など、実装に関する話

プロジェクトを成功させるためには、「効率よく仕事を進める」「手戻りや足止めの時間を減らす」みたいな事を頑張りたいですよね。
タスク間の依存関係をほぐしたり、属人性の高いタスクにスペシャリストが良いタイミングで着手できるように整えるのは、いわゆるプロジェクト管理といわれる領域の成果であり責務です。
それと同時に、いかにソフトウェアを設計するか？によっても、プロジェクト管理のリスクのコントロールに影響します。すなわち、設計次第で「手戻りやタスクのブロックを軽減する」ことに繋がるのです。
これは、突き詰めると「変更容易性」「開放閉鎖原則」で説明することが可能です。

このトークでは、「どのようにして、ソフトウェア設計の観点からプロジェクト管理の難しさを和らげるか」について共有します。
設計と、スケジュール管理と、チームによる分業を総合して考えることで、よいプロジェクト人生を手に入れましょう！！

話すこと

• 「どこから作っていけば良いのか」で考えるPJの進め方
• 「ハリボテ」を活用して、実装の意思決定を遅延させる
• それでも「後回しに出来ない実装」にチームで如何に立ち向かうか

主な参考書籍

• アジャイルソフトウェア開発の奥義
• ライティングソフトウェア
• 実践テスト駆動開発

【前口上】
ありがとうPhpStorm、寛容で叡智に富んだあなたがいてくれて、私のPHPはどんどん良くなっていく───
コードエディタの領域だけではない、ソフトウェア開発を幅広くサポートする強力なツール・機能群。静的解析ツールやテスティングフレームワークといったPHPコミュニティの資産との力強い連携。そして、あらゆる面でコードのクオリティを底上げしてくれる静的解析機能！！

今日では、こんなにも進歩した相棒によってPHPの開発が支えられております。
便利で馴染み深いツールだからこそ、しっかり使いこなして普段の開発をより心地よく・生産的なものにしたいですよね。

【本題】
そんな事を感じながらも、あなたはPhpStormのInspectionについて、どのくらい把握できていますか？
当たり前のように目にしており、時には自分で調整をしてみるものの、あまり網羅的に内容を観たことがない・・という人も少なくないのではないでしょうか。

本トークでは、PHPについてのInspectionを全体的に眺めてみつつ、現場で実践的に活用するための方法を共有します。

主に話す内容

• PhpStormのInspectionってどんなものがあるの？
• ちょっとした付き合い方のコツ、個人やチームで上手く使う
• 自作のインスペクションを追加する

Google Apps Script（以下、GAS）とは Google が提供するローコードプラットフォームです。

普段 JavaScript を書くのほぼ同じ感覚でコードを書いて実行できますが、単なる JavaScript 実行環境にとどまらず Google の提供する各種サービス（スプレッドシートやフォーム等）との連携を容易に行えたり、動的な Web ページを表示できたりと、まさに「ローコードプラットフォーム」と呼ぶにふさわしい機能を備えています。

何が正解かわからないビジネスの世界において、誤った方向性でプロダクトを作り込んでしまうことを避けたいもの。
そのためにコストをかけずにプロトタイプを作って仮説を検証するのですが、GAS の備える特性はそのサイクルを回す際に強力な助けとなります。

本トークでは、そんな仮説検証を回すため知っておくと役に立つ

• GAS でできること
• GAS を使うときのコツ、Tips
• GAS の限界、使うべきでないところ

についてお話します。

フロントエンドやバックエンドのような技術的関心事で担当領域を区切るのではなく、プロダクトが価値を提供するために技術面全般へ責任を持つ「フルサイクルエンジニア (full-cycle developer)」という考え方があります。

本トークでは、フルサイクルエンジニアという働き方についての説明と、私がフルサイクル開発者として5年ほど仕事をしてきた中で「良い仕事」をするために意識していることをご紹介します。

対象観客

• フルサイクルエンジニアという考え方に関心があるかた
• フロントエンド/バックエンド/インフラだけを専門的にやっているがこれで良いのか？という悩みを抱えているかた
• プロダクトについてもっと責任を持ちたいと考えているかた

話すこと

• フルサイクルエンジニアとは何か
• フルスタックエンジニアとの違い
• 専門性についての懸念
• どうあれば「良い仕事」と言えるのか
• 「良かった」とフィードバックを貰えた仕事例

コロナ禍をきっかけとして、テレワークを導入した企業は珍しくないでしょう。
もともとソフトウェアエンジニアにとってテレワークは相性が良い部分もあったことから、様々な利点をもたらしてくれました。
その一方で、良いことずくめに思えたテレワークも、新たな問題をもたらしたこともまた事実でした。

従業員どうしの関係性や勉強会等の活発さといった文化をひとつの強みとしていたエンジニア組織は、テレワーク導入直後にはその強みがほとんど見えなくなっていました。
もともと組織には「開発組織活性チーム」というチームが存在しており、テレワーク導入による問題が無視できなくなってきた頃、「失われつつある組織文化を取り戻し、維持すること」を新たなミッションに掲げて活動内容を変化させました。

本トークではそこからおよそ 2 年にわたる「開発組織活性チーム」の取り組み内容と、それによって実現できたこと、できなかったことおよびそれらの考察をお話します。

家を買うべきか、買わないべきか。
買うとしたらマンションか、戸建てか。
勤続年数が浅かったりフリーランスだと住宅ローンの審査が通りにくいという話は本当か。

家の購入って分からないことが多すぎて無限に悩みますよね。

本トークでは、家を購入するに当たって自分自身が調べたことや不動産屋に相談したことからの学びをご紹介します。

対象観客

• 家を買うか買わないかで迷っている
• 転職・独立を考えていて、住宅ローンが組めなくなるのか不安
• 家を買おうと思っているが何を気にするべきか、いくら現金を用意する必要があるか知りたい

話すこと

• 家を買うべきか、買うべきでないか
• 物件を選ぶときに考慮するべきポイント
• 家を購入するのに必要なお金
• 住宅ローンうんちく (金利、返済方法、借りやすい金融機関)

（PHPerKaigi 2023でパンフレットに寄稿させてもらった https://fortee.jp/phperkaigi-2023/proposal/caec413f-384d-415e-8020-59053058a1f6 のトーク版です）

今ではオープンソースソフトウェア（OSS）を使うことは当たり前になっています。このことに異論を挟む人はいないでしょう。

ところで、「OSSへのコントリビュートをするのは敷居が高い」「OSSを作るのはなかなか難しい」とよく聞きます。
確かにそれもOSSの1つの側面かもしれません。

そこで提案です。趣味としてOSSを書くのはどうでしょう？
実はOSSは趣味で書くのもアリなのです。
皆さんの中にも「プログラムが好き」「プロダクトが好き」「モノづくりが好き」という方は少なくないはずです。
そんなあなたは趣味OSSの素質ありです。

筆者は「少し実用的で小さなOSSを書くのが趣味」と公言しています。
あくまで「いち趣味の紹介」としてOSS開発のはじめかたをお伝えできればと思います。

そして、オフライン発表だからこそできる、私の積みOSS（ネタ帳）を全てお見せします！
これは発表資料には含めない予定なのでその場限りの公開になるかもしれませんよ。

みなさんはこういった経験が無いでしょうか。

「PHPStanのレベル5まで対応完了！よしっ！」
「つづいて、レベル6っと、ッターン！」

Method xxx() return type has no value type specified in iterable type array.

「ふぁっ！？」

、、、はい。あると思います。
そんなときはArray shapesなりで、ひーひー言いながら対応すると思いますが、泣きながらこう思った人も少なからずいるのではないでしょうか？

「PHPStanはLevel6で何を見ているのだろう」と。

今回のトークでは、そういった疑問をソースコードリーディングを交えながら、みなさんと一緒に解き明かそうと思います。
PHPStanが見ている世界を知ることができれば、PHPStan(ひいては静的解析ツール)ともっと仲良くなれるはず！

■ 話すこと

• PHPStanのレベル6について
• レベル5とレベル6での解析方法の違い
• 字句解析, 構文解析, 評価 について少し

■ ターゲット

• PHPStanの対応(特にレベル6)で苦労したことがある人
• PHPStan(静的解析ツール)と仲良くなりたい人

webサービスを開発する上で、脆弱性への配慮は非常に重要です。
皆様も一般的な脆弱性については意識をされているかと思います。しかし、マイナーな脆弱性についてはどうでしょうか？
本セッションでは Laravelにおいて実装された5c問題の脆弱性を持つデモ用のweb applicationを攻撃し、脆弱性の説明を行います。

対象

• セキュリティ対策の基本について興味のある方
• 具体的な文字コードにおける脆弱性の仕組みに興味のある方
• ctfに興味のある方

内容

• sql injectionの説明、blind sql injectionの説明
• 5c問題はなぜ起こるのか
• laravelの実装と実際のデモ
• 安全に実装するための注意点

文字コードの知識を活かしたsql injectionの防止を通じて、セキュリティへの関心を高めましょう。

webサービスを開発する上で、脆弱性への配慮は非常に重要です。
皆様も一般的な脆弱性については意識をされているかと思います。しかし、マイナーな脆弱性についてはどうでしょうか？
本セッションでは laravelにおいて実装された5c問題の脆弱性を持つデモ用のweb applicationを攻撃し、脆弱性の説明を行います。

対象

• セキュリティ対策の基本について興味のある方
• 具体的な文字コードにおける脆弱性の仕組みに興味のある方
• ctfに興味のある方

内容

• sql injectionの説明、blind sql injectionの説明
• 5c問題はなぜ起こるのか
• laravelの実装と実際のデモ
• 安全に実装するための注意点

文字コードの知識を活かしたsql injectionの防止を通じて、セキュリティへの関心を高めましょう。

この発表では、Laravelを使ったWebアプリケーション開発において、誤った実装やセキュリティに関する不注意によって生じる脆弱性(XSS、CSRFなど)について説明します。また、それらを回避するための対策方法について説明します。

主な対象

• Laravelを使って開発をしている方
• セキュアなWebアプリケーションを開発したい方

話すこと

• Webアプリケーションの攻撃手法について
• Laravelにおける誤った実装やセキュリティに関する不注意によって生じる脆弱性とその対策方法について

太古の昔、サーバーの設定をいじるとなると、プロフェッショナルなインフラエンジニアにお任せだったと聞きます。
我々（PHPer）の手に負えない程大きくなったインフラの管理は、それこそ職人技だったのだと想像できます。

一方現代、インフラの多くはクラウドです。
皆さんもAWSなどを活用していると思われますが…形だけのクラウドになっていませんか？
クラウドの登場で誰でもポチポチ簡単にサーバーを建てれるようになりました。が、"本番環境にそびえ立つ謎のサーバー"や"誰も設定がわからないLB"などオンプレ時代とそう変わらない問題を大なり小なりどの現場も抱えているかと思います。
我々はいつまでコンソールの画面をポチポチしてサーバーを作るのでしょうか？

昨今IaC呼ばれる便利ツールが流行っています。ただ、メリットがわかっていても、「キラキラでなんか怖い！」「うちには導入できない！」と思われて二の足を踏んでいる方もいることでしょう。
大丈夫です。我々が「ポチポチコンソールによるAWS」から「IaCによるAWS」にマイグレーションした過程をお話します。
「最初からすごい人がいたんじゃないの？」と思われるかもしれませんが、そんな事ありません！移行の過程で一つずつコード管理を進めました。
いまあるサーバーを動作させながら少しづつIaC化しましょう！

本トークでは
・TerraformなどIaCをつかうメリットを紹介
・アプリケーションエンジニアがTerraformを使えると良い理由
・ポチポチコンソールで作成した現在稼働中のサーバーを、Terraformで管理する方法・Tips
を話したいと思います。

※話さないこと
・ツールのインストール方法や、チュートリアルレベルのお話
・PR TIMESのAWS移行時の具体的な作業の説明

本トークを聞き終わった後に、PHPerのみなさんが「自社のサーバーをIaCツールで管理したい！俺らの手でやるぞ！」と思えるトークを目指します！

echoとprintって何が違うの？
for と foreach , whileの違いと使い所って？
早いコードと遅いコードってどのくらい差があるの？
php8.2に存在するビルトイン関数をopcodeを見て感覚ではなく理論で理解しよう！

話すこと
PHP8.2のビルトイン関数の紹介
類似した関数のopecodeの比較
早いコードと遅いコードの比較と関数の得意な処理の説明

今年に PHPerKaigi 2023 というイベントで、「時間を気にせず普通にカンニングもしつつ ISUCON12 本選問題を PHP でやってみる」というトークをしました。
https://fortee.jp/phperkaigi-2023/proposal/7e212cb2-be37-43e8-b6ee-5236d259fcbf

時間無制限バトルによって、結果的には ISUCON12 の優勝チームが Go で出した本選スコアを PHP で越えることができました。しかし、このときのチャレンジではまだ幾つか試せていない取り組みもあります。

例えば他言語で行われるような、オブジェクトのプールを事前生成して使いまわすような最適化には PHP でも意味があるのでしょうか？
実行時型検査のコストをバイパスするような最適化は可能なのでしょうか？
immutable_cache のような別のキャッシュソリューションに目に見える効果はあるのでしょうか？
Workerman や他の非同期 PHP フレームワークのような、さらに異なる PHP 実行環境との性能比較はどのような結果になるのでしょうか？

思いつくままにいくつかの挑戦を追加でやってみます。

対象とする聴講者は以下です。

• 横に並べるサーバ台数を増やせない環境下での PHP の限界チューニングに興味のある人
• PHP で ISUCON を戦っていきたい人
• PHPerKaigi 2023 の元トークの内容を知っていて「この先に行くにはどうすればいいのか？」と思った人

OpenTelemetryはObservabilityを獲得するための標準化されたSDK・API・ツールの提供を目的とした、CNCFのオープンソースプロジェクトです。
CPU使用率のようなシステムメトリクスから、アプリケーションのカスタムログまで、様々な情報を言語やプラットフォームに依存しない統一的な規格で管理できます。
モニタリングツールもJaegerやPrometheusといった主要なOSSとの連携がサポートされているだけでなく、DatadogやNew Relicのようなベンダーサービスにも出力を取り込めるようになっています。
10種以上の言語への対応が進んでいる中、ついに昨年12月、PHPのSDKがv1.0.0になりました！
4月現在まだbetaですが来たるGAに備えて、便利に使いこなすために、OpenTelemetryがどういうものか、何に使えそうかを今一度みていきます。

話すこと

• OpenTelemetryとはなにか。コンセプトと仕組み
• どうやって使うのか
• なにが出来るか
• 実際のコードを使ったトレース、メトリクスの監視デモ

想定する聞き手

• 監視に興味のある人
• 独自のトレース、メトリクスを収集したい人
• オープンな標準規格に寄せて連携先をお手軽に切り替えたい人

開発環境を柔軟に構築でき、それを簡単に共有できるDockerですが、都度適切な環境を構築することが新米エンジニアの私にはとても高いハードルでした。
しかし、ある出来事によりそのハードルがここ最近ガクッと下がりました。AI技術の急速な進化です。

このLTではAIツールを活用して0からDockerでLaravel環境を構築できた実体験をお話しすることで、
Docker × Laravel環境の作り方をわかりやすくご紹介すると同時に、プログラミングにおけるAIツール活用のコツも少しご提供できればと思います。

話すこと

• DockerでLaravel10環境を構築する流れ
  • ディレクトリ構成・ファイル構成
  • 設定ファイル（Dockerfile、compose.ymlなど）の書き方
• AIツールをプログラミングに活用するためのコツ

対象者

• DockerやLaravelをなんとなく知ってはいるけど使いこなすことは難しいと感じている方
• AIツールをプログラミングに活用したいと思っている方

コードを書いていて自分で命名をする機会って多いですよね。
良い命名をすることで、コードの可読性が向上し、保守性も高まります。一方、悪い命名はコードの理解を困難にし、ソフトウェア品質を低下させる原因となります。
実体験、書籍、ウェブ記事や他のカンファレンスで学んだことを総合的にみて、どんな命名をすべきかを具体的なコードを示しながら発表します。

本発表の目的は、良い命名の条件と具体的な命名方法を理解し、実践につなげることです。

内容

• 命名の重要性
• 悪い命名の例とその影響
• 良い命名の条件と具体例
• 実践で使える命名方法
  • 変数の命名
  • メソッドの命名
  • 命名の場所

PHPで文字コードを扱うには、mbstringを使うのが主流であると思います。
そんなmbstringですが、PHP 8.1からMajor Overhaul of mbstringという大規模改修が入ったため、その内容を把握するための記事を書きました。
運良く、執筆者であるAlexさんに読まれたことで、ぼくはPHP 8.3となるバージョンの面倒を見るという立ち回りをしています。

文字コードはそれぞれ生まれも管理の方法も違うため、色々と混乱することもあるでしょう。
特にShift_JISのたくさんの亜種などはたくさんありすぎて何がなんだかわかりませんよね。
そういったものを紹介していければいいなと思っています。

また、PHP 8.3では、どうやらUTF-8を使うのがよさそうというのがわかってきました。
一方で、Shift_JISやISO-2022-JPなどを使うというのも選択肢としてあるようです。
それにはUTF-8特有の弱点も存在していて、Shift_JISが好まれる理由でもあるようです。

文字コード、それぞれ先人の歴史の積み重ねによるものが多いです。
一度、棚卸しを兼ねて文字コードを見てみませんか。