トーク

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

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

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

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

概要

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

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

話すこと

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

トークの流れ

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

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

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

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

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

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

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

狙い

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

対象

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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