オンプレだったPHPアプリケーションをコンテナ化してWEBとバッチをクラウド化（AWS）しました。
今まで全くインフラの仕事はしていなかったのですが、ずっと興味がありました。
そして機会があったため手をあげて、SREと協力しながら実現させました！

「普段アプリケーションをさわってるけど、インフラもやっていきたいんだよなあ・・・」と思っている人のはじめの一歩を
私が体験した作業を軸に「やわらかく理解」できるようにお話します！

◆ 想定する観客
1年前の「インフラ興味あるけどなんもわからん」と思っているアプリエンジニアの私向けに作ります
総合して初学者向けです

◆ 話すこと
クラウド化で発生する作業って？（ECS / Docker / デプロイ / … ）
実際のタスクを進める上での悩み・詰まりポイント
クラウド化後に起こった想定外だったこと

DX(Developers eXperience) という言葉を聞いたことはありますか？ Digital Transformation の略称として使われることも増えていますが、別物です。
IT エンジニアの需要が増加傾向にある昨今、「コーディング自体を助ける 『優れた開発者体験』 」が重要視されています。

このトークで話すこと

このトークでは、潤沢な Laravel エコシステムを活用して、 DX を最大化させ、効率的なアプリケーションの開発を行う手法を紹介します。

• ローカル開発環境(Sail)
• 静的解析, Pint と Pest
• ファーストパーティ認証システム
• React フロントエンドバンドル(JetStream+Inertia.js)

ターゲット

Laravel を用いて効率的で安全にアプリケーションを開発したいあなたに。

業務知識とコードがリンクしていないと、PdMやビジネスサイドと会話をした時に上手く噛み合わなかったり、ある業務に関するコードを変更した際に思わぬ副作用が出たり、ビジネスサイドからの機能要望に応えることが根本的に厳しい状況に陥ると自分は考えています。

トーク内容

新卒二年目の自分がやっている業務知識とコードを結びつけるためにやっていることをお話しします。

話さないこと

• DDDについて（意図せずDDDっぽいことを話すかもしれませんが、DDDについては全くの素人なので悪しからず

エンタープライズアプリケーションアーキテクチャパターン(以下P of EAA)は、有用ですがなかなか読み解きにくい本です。

このセッションでは、P of EAAのパターンに基いた構成になっているEloquentと関連付けることで、P of EAAのデータソースレイヤ回りのパターンの概要を、わかりやすいく説明します。

1995 年から 30 年近く進化を続けている PHP 。私はその歴史でも一つの大きな転機となった PHP 5.3 あたりから、 8 年ほど開発に携わっています。
ここ 5 年弱の PHP の変遷はめざましく、大きくその姿を変えています。 IT 業界が揺れ動く中でも安定した需要を見出しているのではないでしょうか。

このトークで話すこと

このトークでは、これらのことについてまとめています。

• これまでの私の知りうる限りの PHP の進化の過程
• 現在の PHP 8.2 時点で作れる堅牢なアプリケーションの作り方
• この先 PHP がどういった道を進むのかを RFC を見ながら想像

ターゲット

• これまでを振り返りたい方
• 今どう書くのがオススメなのか知りたい方
• 未来の PHP に期待している方々

PHP に関わるみなさんに聞いて欲しいと考えています！

「ユニットテストなんてダルいよなー」「疎通動確の方が速いよなー」
そんな方へお届けする「気張らないでやれる」「"プログラマにとって"有用・有益なユニットテスト」についてのお話です。

また、次の症状にお悩みの方にも有効です。
・ユニットテストはやってみたいけどPHPUnitの導入で挫折した
・PHPUnitほど高度ではなくて良いので、もうちょっと気軽にユニットテストしたい
・大分古いPHPからのバージョンアップを実施したい
・バージョンアップのたびに動かなくなるテストスイートってどうなの

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

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

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

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

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

想定対象者

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

以前PHPカンファレンス沖縄2022のLTで発表では5分で概要だけお話したことがありますが、語りきれていないことが沢山あるため拡大版です。

現在国内最大級の規模であるInstagram分析ツールSINIS for Instagramは2019年2月〜2019年8月の約7ヶ月でにフルリプレイスを行いました。

リプレイス前のコードやインフラはどういう状態だったのか、どういう理由で今の技術選定を行い、どういう構成になったのかの技術的なお話はもちろん、エンジニア以外にどうリプレイスが必要なのかを説得したかといった技術のお話以外まで公開します。

また、リプレイス完了からしばらく期間がたっているので、今よかったなと思うことだけでなく、今振り返ると当時これやっときゃよかったな〜とかのしくじり部分のお話もさせていただきます。

会社で開発を続けると突然やってくるだろう「リーダーやってみる？」
コードを書くほうが好きだけど、何となくリーダー経験してみようと思い立ったエンジニアの1年の軌跡をご笑覧あれ。

▼想定ユーザ
同じくリーダーをやってる、やっていきたい方
困ってる人を見て楽しみたい方

▼話すこと
認識していた役割と実際とのギャップ
見えてくるチームの課題
何を武器にしてプロジェクトを進めるのか
メンバーとプロジェクト、組織との向き合い方
情報を集める方法と実践してよかった施策
等など

マネージャ「すぎやま君には後輩の成長支援をお願いしたいんだよね」
僕「僕もまだ成長したい側なんですが？」

突然、後輩の成長支援をすることになりました。いったい何をしたら良いのでしょうか？
後輩からエンジニアのキャリアパスについて聞かれた場合、どう答えることが適切でしょうか？
また、php-srcに詳しいような自分よりもハイスキルな後輩たちに対して支援することは可能でしょうか？

このトークでは、成長支援が必要になった背景、支援するための準備や工夫、気をつけていること、悩んでいること、
そして、成長支援を通して自分自身が成長したことなどをお話しします。

PHP5系を使い続ける社内システム。色んな制約があり、バージョンアップできないことよくありますよね？

本トークでは、そんなレガシーと呼ばれるシステムと向き合う時の注意点やそもそもの要件を探り当てる嗅覚の話ができればと思います。

みなさん、システム設計はしてますか？ どのように進めていますか？

このトークでは、私が Catlog （※1）のアプリケーションの新機能などを作る場合の設計時に考えていることや、利用しているツール、チーム内外に共有する手法などを具体例とともにご紹介したいと思います。

なお、ここでの「システム設計」には「ソフトウェア設計」も含まれますが、それだけでなくもう少し広い範囲での「設計フロー」を想定しています。

想定対象者

• システム設計に興味のある方
• 他人の設計のようすを垣間見たい方

備考

• ※1 https://rabo.cat/catlog/

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

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

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

開発ではコードを書く時間よりも読む時間の方が長いと言われていますし、コードレビューを通してコミュニケーションをとることも日常茶飯事です。
そんなとき、このような経験は無いでしょうか？

• 何をしている変数なのか全然わからない
• メソッド名からは伝わらない実装のサプライズ
• コードコメントが実装を説明しただけ
• 何をどういう条件で検証したいテストなのか不明
• コミットメッセージが「指摘箇所修正」ばかり
• PRで実現したかったことがわからず本質的なレビューができない

命名であったり設計であったりコードレビューであったり分野は少し異なっているように見えますが、これらは全て書き手が選択した「言葉」を使って表現されているという共通点があります。

本セッションでは、「言葉」という共通点に注目しつつ、チーム開発において伝わる「言葉」とは何か、伝えるために必要なことについて発表します。

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

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

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

株式会社LATRICOは2020年創業のヘルスケアスタートアップで、東京美肌堂というサービスをLaravelで開発・運用しています。
創業当時は業務委託を中心に開発を進めていましたが、2022年からエンジニア採用を始めて徐々に内製化を進めてきました。
そんな会社にCTO（二人目のエンジニア）として入社し、どのようにプロダクトを改善してきたかの泥臭いお話をさせていただきます。

トーク内容

• プロダクトの紹介、当時の問題の共有
• 開発ロードマップの策定
• 採用
• 実装方針の共有・レビュー体制の構築
• CI/CD整備
  -- phpcs, phpstan,PHPUnit整備
  -- ブランチ運用ルールの変更
  -- デプロイフロー変更
• サービス安定化
  -- DataDog, Sentry
• 監査対応
  -- 障害報告フローの整備
• そして脱PHPへ…

プロポーザル一覧をご覧ください！「10年もののコード」「20年続いた老舗の味」といった表現が出てきますよね。
何となく「ソフトウェアは経時的に劣化する」というのは広く知られているかのようです。
また、「今のリリースで出たバグ」と「5年前のコードの間違い」では、前者の方が虫退治が簡単である事が多いです。
これも「ソフトウェア-開発者-時間」の問題に思えます。

こうした文脈での「時間が経つ」とは何なのか？「"時間の経過"を遅らせ、進化を早める」ことは可能なのでしょうか。
このトークでは、「時間」を切り口にソフトウェア開発の難しさを考えていきます。
プロジェクト管理や品質に関して思いを馳せる土台になれば幸いです

主な参考書籍

• ワインバーグのシステム思考法
• ライティングソフトウェア
• レガシーコードからの脱却
• A Philosophy of Software Design

近年 DevOps の話題についてよく耳にするようになりましたが、私達のチームでも最近 DevOps のプラクティスの1つ「継続的デプロイ」を導入しました。
コード変更が発生する度に本番環境に自動デプロイを行うことで Four Keys の「デプロイ頻度」や「変更のリードタイム」の改善に直接的に寄与する一方、コードの欠陥がすぐに本番環境で発露するため、システムの信頼性を毀損するリスクも伴います。
私達のチームでは特に信頼性を損うことなく導入を進めることができたように思います。
振り返ってみると、サービスリリースから4年半の間に行った様々なデプロイ戦略の改善の結果、継続的デプロイ導入の下地が出来上がったのではないか、と考えるようになりました。

このトークでは過去に行ってきたデプロイ戦略を中心とした開発フローの変更と、それらがどのように継続的デプロイ導入に役立ったのかについて話します。

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

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

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

もっと技術的なチャレンジがしやすい環境を作りたい。

サービス全体の技術力を上げていくためには、そこに対して投資する姿勢や技術的なチャレンジがしやすい環境を作る必要があると考えています。
どうすればそんな環境を作ることができるのか。
まずは、早くて安定したリリースができる仕組みが必要であると考え、Four Keysで開発パフォーマンスを可視化し改善のためのアクションを繰り返しています。
このセッションでは、Four Keysを活用した開発パフォーマンスの改善をチーム全体を巻き込みながら進める方法についてお話しします。

【トーク対象】
・Four Keysをサービス改善に活かしたい方
・開発パフォーマンスを改善したい方
・チームを巻き込んで改善していきたいことがある方