名付け、してますか？ふと気付けば、常に名付けばかりしているのではないでしょうか。
できる限りわかりやすい名前を付けようと一日の稼働時間を潰した経験はありませんか？

日々当たり前のように名付けをしていますが、これは我が子の命名と同じくらい大切な行為です。

名前を付けることで何が起きるのか。「名付けできない画面」とはどういう状態なのか。
名付けに対しての意識を、今こそ改めて考える。そんなトークができればと思います。

AWS App Runner PHP8.1がサポートされました！

AWSにてマネージドにPHPを利用できる環境として、注目が集まるAWS App Runnerですが、
Production利用は可能なのでしょうか。

AWS Lambda PHPのProduction利用の回数も重ね、
マネージドPHPのノウハウが少しずつ溜まってきたので、
そのノウハウとも比較しながらAWS App Runnerの可能性を探ります

• お話すること

  • AWS Lambda PHPについて
  • AWS App Runnerについて
  • ２つの環境の比較

• 想定する聴講者

  • AWS Lambda PHPに興味がある人
  • AWS App Runnerに興味がある人
  • マネージドな環境に興味がある人

「本にはこう書いたけど実は...」で始まるお話をしたいです。書籍はネット記事や論文と違って、いつまでも本屋さんに置かれる商品なので、考えることがいろいろあります。どんな手口で何をたくらんでいたのか、書いてないけど裏で考えてたことは何か、なんでアレをそう書いてコレはこう書いてないのか... ここでしか言えない (Twitter で漏らしてしまうかもしれないけど) ことを語らせてください。

昨今、WebAssemblyへの注目度や活用が盛んになってきています。Kubernetesへの利用 やdocker desktopで動作可能になったり、ブラウザ以外への利用も広まってきています。

特にPHPerから見ても実用性のある技術になってきていると感じており、wordpress-wasmを始め、ブラウザ上でPHPを動かすという世界観も現実味を帯びてきました。

そこで今回のトークでは、PHPをWebassemblyを用いてブラウザ上で動かす技術を紹介します。
デモとして実際に動かしてみて、そのために必要な技術や課題観を皆さんに共有できたらと考えています。

ウェブアプリケーションが思ったほど速度が出ないときに、"Cache"を利用することは多いかと思います。 例えば、実行時間のかかる SQL クエリの結果を "Cache" したり、複雑な計算処理の結果を "Cache" したりです。
しかし、パフォーマンスが上がるはずなのに、思ったほど効果がでないということがあります。そんなときは、"Cache" の基本に立ち返って、理詰めで考えてみることをおすすめします。

本トークで話すこと

• Cache とは何か、どのようなときに利用するのか
• Cache によって、改善されるものは何なのか
• PHP において利用可能な Cache の種類と効果
• ウェブアプリケーションのベンチマーク結果

Webサイト制作を仕事として受けているか否かに関わらず、
企業から相談を受ける立場で仕事をしていると、定期的にやってくるのが「Webサイトがハッキングされた！」という駆込みです。

私は会社員時代も含め、かれこれ10回以上この手の相談を受けてきました。
そしてそのほとんどは、Webサイトのサーバにバックドアを設置された事案でした。

WordPress 等の普及によって、本来システム屋ではないWebサイト制作事業者が気軽に PHP を動かすようになったことがその大きな要因ですが、
それが PHP である以上、我々 PHPer にとっても他人事ではありません。

今回のセッションでは、実際に PHP でバックドアプログラムを書きながら、

・バックドアとは具体的にどのようなものか
・原因と対策
・我々 PHPer に何ができるのか

をお話しします。

例えば消費税や販売手数料等の金額計算をしなければならなくなったこと、ありませんか。
var_dump(0.1 + 0.2); が何を表示するかすぐに答えられるでしょうか。
このトークでは、PHPで任意精度演算を行って「正しい」金額計算を行う方法について説明します。
なんとなくintやfloatを使って計算するのは、もうやめにしてみませんか。

想定対象者:

• PHPで任意精度演算を今までやったことがない人
• 任意精度演算という言葉を初めて聞いた人

ISUCON は「いい感じにスピードアップコンテスト」の略で、ほぼ同様の処理をするよう作られた Web サービスの参考実装が複数の言語で用意され、参加者は競技中好きな言語を選んでその性能改善をしていきます。2022 年に実施された ISUCON12 の本選参加チームには PHP は使われなかったのですが、参考実装はきちんと存在しています。

このトークでは ISUCON12 本選問題の PHP 参考実装を使い、時間制限を気にせず、本選参加者の感想ブログの取り組みを平然とパクりつつ、PHP でどこまでスコアが伸びるか試した際の知見をお話します。

PHP はサービスをいい感じにスピードアップするのには不向きなのでしょうか。Go のような本選常連組の言語にはかなわないのでしょうか。それとも、本選で良い成績を残した他言語の参加者と同じ取り組みをすれば、同じようなスコアが出せるものなのでしょうか。

PHP は歴史の中で大きく進化し，PHP 7 からは本格的に型付けをサポートし，PHPStan や Psalm といった強固に型を静的解析するツールも生まれました．チームで PHP を用いて開発していると，型や静的解析の方針や方法に差異が生まれてしまうことがよくあります．しかし，安全に継続して開発をしていくためには，その手法を統一し体系立てて利用されるべきです．また，手法から外れて開発を行うプログラマからコードを防衛すべきです．

このセッションでは，そうした防衛的な手法を多く取り入れて，安全に，長く PHP を使って（バージョンアップに遅れを取ることなく）開発を続けていくための方法をご紹介します．

話すこと

• PHP 8 時代の型・型検査
• 静的解析・フォーマットと IDE

話さないこと

• 静的解析や型を取り入れるべきかどうかの議論
• きのこ派かたけのこ派かの議論

PHP における参照に似た機能は、他の言語にも存在しています。C のポインタ、C++ の参照、Java の参照型、C# の参照渡し……。しかしこれらは、それぞれ細かな点で PHP のそれとは異なっています。
PHP における参照を完全に理解すべく、1) PHP レベルでの挙動を観察し、2) PHP 処理系 (https://github.com/php/php-src) のソースコードを追いかけます。

対象: 重箱の隅をつつきたい PHPer、または PHP の language lawyer になりたい人。PHP 処理系は C で書かれていますが、C の知識は (あまり) 要求しないようにするつもりです
目標: PHP の参照を、実装レベルで完全に理解すること、また、php-src を少しだけ探索できるようになること
話さないこと: 参照のメリット・デメリットや使うべき場面

「composer install打ったらいい感じになるよね」「なんかDockerfileに書いてあるよね」
かつて私のComposerとの向き合い方はこのレベルでした。
しかし自サービスをコンテナ化するにあたり、Composerときちんと向き合い彼らとの絆を得ました。
本セッションでは「Composerってなんだっけ？」から入り、Dockerコンテナにおける取扱いまで触れていきます。

◆ 話すこと
基本的な役割
主なコマンド
composer.json？composer.lock？
いろいろな実行方法（コマンド・composer.phar・Docker Image）
Docker(コンテナ)とComposer（マルチステージビルド）
自サービスで最終的に採用した方法とその理由

◆ 想定する観客
Composerをなんとな〜くで使っている方
Docker環境でComposer使いたい人

PHP ParserとはPHPのコードをパースするライブラリです。これは静的解析やコードの操作等に用いられます。例えば、PsalmやPHPStanがこれを利用しています。

そんな言わばPHPを最もよく知るライブラリからPHPのことを学ぼうというのが本トークのテーマです。

本トークではPHPを構成する要素に着目します。PHP Parserはコードをパースし、ノードと呼ばれる単位に分解します。静的解析はノードを一つ一つ読み取り、コードを解釈します。ノードは170種類以上あるのですが、それはPHPが多様な要素から成ることを物語っているように思います。

ノードの定義を読み解くことで、PHPにおける文や式とは何なのか、どんなバリエーションがあるのか、PHPはどんなパーツから成り立っているのか等を確認したいと思います。（また、その過程でPHP Parserについても少し理解できると思います。）

概要

このセッションは、自社での「データの民主化」の過程でうまくいかなかったことから得られた学びと、
その学びをどう生かしているのかという話をします。

「データの民主化」と調べると、データ基盤の構築や、BIツールの導入、ダッシュボードの構築などの話が多くでてきます。
これらは大事なことですが、しかしこれらを作っただけではデータの扱いに慣れていない方には一向に広まらず、
一部の人しか活用できてないという結果だけが残ってしまい、これだけでは「データの民主化」にはならないということを学びました。
この学びから、アプローチを変え再度「データの民主化」に挑戦していると話をします。

話すこと

• データ基盤構築の話(ちょっと)
• 最初の導入でうまく広まらなかった話
• データの民主化のための泥臭い取組

話さないこと

• 使っているツールについての説明

PHPのプロセスは非常に脆く、簡単に処理が停止してしまいます。
処理途中で切断され意図しないデータが残ったりするケース、皆さん誰しも経験があるんじゃないでしょうか？
シグナル制御を行うことで処理を安全に終了することができます！

• データをキレイにしてから終了する
• どこまで終わったかを通知してから終了する
• 処理が終わるのを待ってから終了する

本セッションでは、安全にプロセスを停止するためのシグナル制御について解説します。

みなさん、 Rector は使っていますか？

近年 PHP を語る上で欠かせなくなりつつある各種静的解析ツールですが、中でも Rector は PHPStan に由来する静的解析のパワーを最大限活用し、コードを意図した形に変換してしまうパワフルなツールです。最近 PhpStorm も標準で対応するなど、盛り上がりを見せています。

今回はこの Rector を最大限活用し、実際にプロダクション環境の PHP を 7.4 から 8.1 にアップグレードしたときのお話をさせていただきたいと思います。

情報共有には「正しい文章」もさることながら「図で示す」のも重要です。

手書きで図を描いたり作図アプリで記述しても良いのですが、ここでは PlantUML によるテキストベースで図を描く方法について注目していきたいと思います。

「UML」と聞いて「仕様や細かいルールがあって難しい・面倒くさそう」と思っていませんか？

全てのルールに従って「正しい UML」を書くことにはとても価値がありますが、一部のルールに従いきれていなくとも「図を示す」ことにも価値があります。

ここでは、PlantUML をがんばり過ぎずにふんわりと使った図の共有についてご紹介したいと思います。

想定対象者

• 図を使ったドキュメントの共有をしたい方
• 図の差分管理をしたい方
• Mermaid 以外の描画ツールを知りたい方

■ 背景
サービスの管理用システムや社内専用システムはどの様にアクセスを制限していますか？
外部からアクセスができないよう会社のIPアドレス限定でアクセス許可を行う形が多いかなと思います。
しかし、これでは在宅勤務時など社外からアクセスできない弊害が……。
そこで、Google CloudのIdentity-Aware Proxy(IAP)を利用し、クローズドなサービスにどこからでも安全にアクセスできるようにします。

■ お話すること
・IAPを活用してサービスを守りつつ、安全にクローズドなサービスを公開していくための構成やポイントをお話します。
・IAPで認証されたことを前提に、パスワードレスで利用できるサービスとしたPHPのコードも交えてお話していきます。

■ 前提
・Google Cloudを利用した構成についてのお話です
・Googleアカウントを使った認証をベースにお話します

みなさんは CodeCrafters というサイトを知っていますか？
このサイトは少し複雑なソフトウェアを作りながらプログラミングを学ぶことができるサイトです。
このサイトではRedisやDockerコマンド、SQLite などの基本的な機能を作るような練習問題があります

Redisを作る課題にチャレンジしました。そこで学んだことを話そうとおもいます。

■話すこと
・CodeCraftersってどんなサイトなのか
・CodeCrafters で Redis を作る手順について
・Redisのプロトコル(RESP)について

■ターゲット
・PHPの基本的な文法はわかるけど次に何をするか悩んでいる人
・PHP以外の言語でなにか作りたいけど作りたいものがない人

『パフォーマンスを改善せよ！』突如下された指令...あなたはこのミッションをクリアしなくてはなりません。
しかし、「方法論を知っていても実施困難」「改善効果が測りにくい」「予測を立てづらい」などの様々な課題を抱えているのが実情です。
では、効率的に確実にこのミッションを遂行するにはどうすればよいのか？

すぱらしいソフトウェアのお医者さん、ロブ・パイクは言いました。「推測するな、計測せよ。」　なんかかっこいい。

このトークでは、この格言の通りにパフォーマンス改善に挑んだ実話を基に「効率的な正しいアプローチ」「パフォーマンス改善方法」をご紹介させてもらいます。

■話さない内容
・詳細なツールの使い方
・解析結果の読み方

■主な内容

・パフォーマンス改善方法の紹介
・パフォーマンス改善業務の進め方
・パフォーマンス改善の失敗談

我々のチームではサービスのメトリクス監視であったり、パフォーマンス可視化にNew Relicを活用しています。
また、開発プロセスの改善や活動量からエンジニアを評価出来る環境作りのために、開発チームのパフォーマンスをNew Relicで可視化、活用しています。
本トークでは、サービスのパフォーマンス可視化だけではなく、開発チームのパフォーマンス可視化も行えるNew Relicについて、弊社の活用事例を時にはコードレベルまで掘り下げながら紹介させていただきます。
サービスや開発組織のパフォーマンスの可視化にご興味のある方々に響くトークをさせていただきます！