トーク

話者は好んでOSSのBrefを利用したサーバーレスのシステムを構築しています

その中で不自由なくLaravelを利用しているのですが、
AWS Lambdaに大きなフレームワークを組み込む事は１つのアンチパターンだと認識しています

しかし自分の体験を元に考えると、本当にアンチパターンなのかを疑問に感じており、
その疑問を解消するために、必要な機能のみ切り出したフレームワークを自作することにしました

フレームワーク実装について学びながら
本当にAWS Lambdaに大きなフレームワークを利用するのが
アンチパターンなのかLaravelと比較しながら検証します

アンチパターンを正面から踏み込むことで、新しい議論の場を作れればと思います

• 想定する聴講者
  • サーバーレスに興味がある方
  • フレームワークの自作に興味がある人
  • Brefが好きな人、気になる人

アプリケーションを安定的に運用していくには、安定した実行基盤を構成する必要があります。
プラットフォームの選択肢としてMicrosoft Azureというクラウドをオススメしたいです。

「PHPとAzure」についての情報はそれほど多くないため、親和性はあまり良くないんじゃない？と思う人もいるかもしれません。
しかし現在のAzureは様々なサービスが提供されており、PHPにおいても様々なシーンでAzureを利用することができます。
PaaSを中心としたアーキテクチャーを構成することで、運用の作業負荷を軽減し、エンジニアが本来の役割や作業に専念するための環境を作ることができます。

アーキテクトや開発者を対象に、Azureで実現するクラウドアーキテクチャーについて紹介します。

【キーワード】
クラウドネイティブ、PaaS、GitHub、コンテナー、CI/CD、サーバーレス、開発環境

概要

ソースコードを整理する方法は数多くありますが、SLA（Single Layer of Abstraction） 原則もその一つです。この原則では、メソッドや関数内に混在するコードの抽象化レベルを整理して、異なる抽象化レベルを持つコードを分離し、同じメソッド内は同じ抽象化レベルとなるようにします。

本セッションでは、この SLA 原則の考え方をベースにして、メソッドや関数、クラス、そしてアプリケーションアーキテクチャにおいて、抽象化レベルを揃えることでより理解しやすいコードにしていく考えを解説します。

話すこと

• SLA 原則とは
• メソッド（関数）の抽象化レベルを揃える
• クラスの抽象化レベルを揃える
• アーキテクチャレイヤの抽象化レベルを揃える
• 抽象化レベルによるテスト戦略

2022年11月のChatGPT登場以降、AIに関する話題は増える一方です。
PHPからは若干、距離があるとも思える生成AIがどのように作られているかを大まかに理解できることを目標とした発表です。
Webアプリケーションなどを開発するPHPエンジニアを対象として、AIと機械学習の概要をデモを交えて紹介します。

• AI・機械学習とは何か
• 機械学習の基礎（勾配降下法）
• AI業界で起きていること
• PHPで機械学習はできるのか？

トーク内でお見せするソースコードはこちらです。手元で見ながら動かしたい方は事前にcloneすると理解しやすいと思います。
https://github.com/yandod/php-ml-example

令和になっても相変わらず紙の書類の需要は大きく、Webアプリ開発においても帳票印刷機能は多くの案件で要求されます。
しかし、これがとにかく面倒くさい。

• 複雑なレイアウトの帳票をHTML/CSSでデザインするのが地獄
• かといって超微細Excel方眼紙でデザインするのはもっと地獄
• しかもPDFに変換するときに微妙に見た目が崩れてどうにもできない

帳票印刷機能を実装したことのある方には強く共感していただけると思います。

そんな面倒で難しい帳票印刷ですが、実は私は既に数年前に最強無敵のソリューションを編み出し済みです。

• ピクセル単位で細かく帳票をデザインできる（しかも簡単に）
• 帳票デザインの保守性が高い（修正が容易）
• 印刷時に見た目が一切崩れない

という条件を満たせる唯一（当社調べ）の方法です。

このトークでは、この至高のソリューションを具体的に解説します！

SPA全盛の時代ですが、凝ったUIを必要としない社内システムなどでは、
まだまだ古き良きMPA（Multi Page Application）構成を採用することは普通にあります。

MPAだとビューのテストは基本的にフレームワークが提供してくれる結合テスト基盤を使って行うことになると思いますが、
結合テストで検証できるのはあくまでHTTPレスポンスの内容までで、その後ブラウザ上で行われるJavaScriptの処理はテストすることができません。

MPAでも一部の画面にだけちょっとしたDOM操作や非同期処理が必要になるケースは多く（例えばいいねボタンとか）、
このようなJSの処理は上記の理由から自動テストがサボられがちです。

このトークでは、こういったMPA上のJSの処理をe2eテストによって楽にテストする方法を、LaravelおよびSymfonyにおける実装例をもとに解説します。

PHPカンファレンスに参加される方の中には、まだプログラミング未経験で、
これからPHPを勉強しようと考えているという方も多くいらっしゃると思います。

そんな方々へ向けて、アプリケーション開発に必須の知識である
データベースやSQLというものを、世界一分かりやすく解説します。

このトークのゴールは

• データベースという概念をなんとなく理解する
• 簡単なSQLを自力で書けるようになる

です。

私自身が「初心者の頃にこういう説明をしてほしかった…」と思うような
順序と言葉遣い、例示を用いて、本当に世界一丁寧に（当社調べ）解説します！
初心者の方の「データベースってなんだか難しそう」という印象を吹き飛ばせたらと思います。

※分かりやすさを優先して厳密さを多少犠牲にする場面があります。上級者の方はご注意ください。
※このトークはPHPに直接関連しない汎用的なトークとなっています。

API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュートを1行追加するだけで一瞬でREST APIを作れてしまう優れもので、
Symfonyのエコシステムにおいては既に決定版となっています。

しかし、ある程度複雑なことをしようとすると途端にフレームワークについての深い理解が求められたり、
痒いところに手が届かず強引なワークアラウンドが必要になったりするという面もあり、入門と実戦の間には大きな隔たりがあります。

このトークでは、API Platformの導入方法から基本機能の概要、さらには実践投入に向けた各種ワークアラウンドや実装テクニックを、
実際に動作するデモをお見せしながら丁寧にご紹介します。

API Platformの実戦投入、あるいはその検討の一助になれば幸いです！

このセッションでは、並行処理のパラダイムシフト、アクターモデルの探求とその魅力に焦点を当てます。
基本的な概念から実践的な利用まで、アクターモデルがPHPの開発者にどのような新たな視点と可能性を提供するかを掘り下げます。
アクターモデルの基本的な概念やダイナミックな特性などを解説、
並行処理の挑戦にどのように対応するのかを理解し、
なぜマイクロサービスアーキテクチャやES+CQRSで協力なサポートを得られるのか、
などなど皆さんの開発へのヒントになるような内容をお届けします。（もちろん失敗談なども）

PHPだけで実現するのは難しいものですが、並行処理の新たなパラダイムであるアクターモデルを理解し、
適材適所に組み込むための手引きとなることを目指します。
アクターモデルが新たな視点と刺激を提供し、PHPによる開発が新たなレベルに達する一助となることでしょう！

プロダクト開発激化時代において、より魅力的で競合優位性のあるプロダクト開発をしていくために開発組織の育成は必要不可欠です。
開発組織の開発力、生産性を上げるために避けては通れない、エンジニア一人ひとりの技術力アップをどのように推進していけばよいのでしょうか。
私がEMとして、ここ数年考え実践してきたエンジニアの教育において必要な要素や考え方について、理論を具体例をおり混ぜながら話します。
（なお、本セッションはPHPカンファレンス福岡と沖縄で話した理論と実践の話の再編になります）

トークの流れ

最初に組織において育成がなぜ重要なのかについて話します。
「個への育成」と「組織への育成」へフォーカスを移し、それぞれへの育成理論や1on1などで使える具体例を紹介します。
最後に弊社で組織での教育の仕組みづくりをどのようにして行い、どのように変わったのかを話します。

本当の初心者向けのセッションです。
このセッションはPHPを始めたいと思っている方、はじめてすぐつまづいてしまった方にゼロからわかりやすくPHPについてお伝えします。
・PHPとはどんな言語か
・PHPをはじめる環境
・PHPの書き方
・簡単なプログラムを作ろう

2023年はAIがとても話題の一年になりました。
わからないことはAIに聞いて楽に進めましょう。
プログラミングを行う上でのAIの使い方などにも触れてゆきます。

本セッションでは拡張性に重きを置いたシステムについてお話しします。

マイクロサービス・モジュラモノリスとアーキテクチャスタイルは多様化していますが、重要なのはスタイルではありません。
本セッションではスケーラビリティを重視します。
スケーラビリティはリソース・コード・組織など様々な観点があり、それらのスケーラビリティの向上はいずれもビジネスにポジティブなインパクトを与えます。

本セッションではそれらを担保するために必要な要素が何かを深堀りし、それらを実現する具体的な技術スタックやアーキテクチャを模索します。
その中でPHPを主軸としたとき、活用しやすい箇所・しづらい箇所についても言及します。

得られる知識：

スケーラビリティの多面的な観点の理解
スケーラビリティを担保する重要な要素とその実現方法
スケーラブルなシステムを実現するための実践的な知識と洞察

会社でマネジメントをやっていまして、エンジニア組織におけるメンバーの目標制度などにも手を出しております
その中で、「ストレッチ目標を立てる」「自分が成長したい姿を意識する」というのを推奨しました。
参考: 過去に書いた記事

これは、組織全体のレベルアップを推し進めたいからであり、その重要なエッセンスである「個人」の成長も仕掛けたいと願ったからです。

実際にやってみて、どうだったでしょうか？
マネージャーでありメンターを担う自分の目線からの手応えや反省・課題と、
実際に目標を設定し取り組んだメンバーの結果(成果、評価)や本人インタビューを織り交ぜて、考察します。

良い点・上手く行かなかった点・難しかった点・合う合わないの話・もっと効果的にするには？のポイント、といったトピックで
実体験をベースに「見えてきたこと」をシェアします

PHP スクリプトがどこでメモリを消費しているのか？
どの参照が意図せず残りメモリがリークしているのか？
何が循環参照を生んでいるのか？

言語としてはもう 30 歳近くになろうとしていますが、 PHP スクリプト内でのメモリの使われ方を知るための選択肢は、意外なほど少ないです。

例えば php-memprof は、PHP 処理系のスクリプト内でのメモリ確保・解放の処理をフックしてリークを見つけ出す素晴らしい拡張です。しかし当然その機構から大きなオーバーヘッドを伴い、本番環境で動作を観察し問題を見つけ出すのには不向きです。

このトークでは PHP 処理系のメモリ管理機構やメモリ使用量計測の事情を解説しつつ、力技の大道芸により PHP で PHP のメモリプロファイラーを実装する取り組みを紹介します。FFI や C 言語レイヤの処理系知識を気軽に使うゲテモノ寄りの話が聞きたい人向けです。

FWの気持ちを理解するのは素敵な事です
では、自作してみるのはどうでしょう？
作れる = 既存FWを読めるようになるという効能もあります

PHPerKaigi 2023で、今風のFWの要件を考察し実装するという発表を行いました
その際に得たFWを例に、実際に動くものを作り上げていく事に主眼を置いて話します
ハンズオンっぽい形やライブコーディング風の説明を多く取り入れるので、是非その場で一緒に手を動かしながら聞いてください

狙い

• FW、怖くない！読める！と思える
  • 普段から気軽にFWのコードリーディングをしちゃう人を増やす
• DIコンテナや、PSR-15/ミドルウェアのイメージを掴む

対象

• FWを(読んで|作って)みたい人
• PSR-7/15やDIについて、聞いた事はある・見かけた事はある人

モノリス全盛期〜マイクロサービスブームを経て、近年、両者のいいところ取りができるアーキテクチャとしてモジュラモノリスが話題になることも増えてきました。PHPでも流行のLaravelフレームワークでのやり方やハマりポイントの記事がありますが、基本的に密結合を指向しているLaravelをベースにかなり無理をして実現している事例を見かけます。
私が数年にわたってSymfony+Doctrine ORMをベースにモジュラモノリスでアプリケーションを開発してきた経験から、Laravelベースで開発するよりも数段楽にモジュラモノリスを実現できることを証明したいと思います。

目の前に立ちはだかる削除フラグ......
削除フラグがアンチパターンであることは知っていても、目の前の削除フラグと付き合っていくしか無い...
そう思って諦めていませんか？

削除フラグを既存のアプリケーションに影響をできるだけ閉じて無くすことはできます。
テーブルから状態や属性を別のテーブルに移し、アプリケーションを壊すことなくリファクタリングしていくために必要なことを説明します。

• 削除フラグがあるテーブルをどうやって分割するか
• 既存のコードの振る舞いを維持しながら如何にリファクタリングするか
• リファクタリングをやりきる ために必要なステップ

レガシィコードと向き合い、リファクタリングして、目の前のプロダクトを改善している現場のテクニック、余すこと無くお話します！

生涯エンジニアを続けたい。
しかしインターネットを見渡せば凄腕のエンジニアばかり。
このまま、自分は生き残れるのだろうか...

私も今年、38歳を越え、職場ではCTOとして決断を迫られる中、それでも新しい技術を理解し、向き合って行かねばなりません。 もちろん一日は有限ですから勉強する時間も限られます。

そんな中、私がどうやって新しい技術を理解し、未来の技術を予測し、今の技術を選定しているか。
そのために日々をどう過ごしているか。そんな "エンジニアとして生き残るためのhack" を皆さんにお伝えします。

ピカソは言った。「優れた芸術家は模倣し、偉大な芸術家は盗む。」

先人の言葉を例に上げながら、課題を解決するエンジニアになるためのロードマップをお話します。

多くのWebサイトではメールアドレスをIDとしてユーザーを管理しています。この設計はフレームワークの機能として用意されることもあります。

しかし実際のサービス運用のためには、いくつかの考慮事項があります。

• ユーザーのメールアドレスの入力ミスによる機会逸失を防ぐ
• 特定の条件のユーザーからの登録を阻止する

要約するとたった二点ですが、実要件は運用形態や提供したいサービスによって様々です。たとえば、同じユーザーからの複数登録を許容しない、特定のドメインからの登録を禁止するなどです。
一見明確でも、単純に実装できない要素がいくつもあります。メールアドレスや関連仕様、DB製品とCollation、メール配信サービスプロバイダ、ユーザー認証プロバイダなども影響します。

メールバリデーションライブラリの実装を通じて、アカウント管理に必要な観点をみつめなおしましょう。