皆さんはPHPアプリケーションにOpenAPIを導入していますか？

OpenAPIとは、HTTP APIの仕様を定義できる言語です。
自動ドキュメント生成やフロントエンドのクライアントコード生成、APIのモック化やバリデーションなど、API開発を支援する非常に強力な機能を備えています。

しかし、既にそれなりの規模のAPIを運用している場合、初期コストや導入難易度が高くなってしまうため、導入を諦めた方もいるのではないでしょうか。

本セッションでは、特定のフレームワークに依存せず、より低コストで安全にOpenAPIを導入するアプローチについてお話しします。

主な対象

• APIを開発している方
• OpenAPIの導入・運用に興味がある方

現場で働くうえでよく分からん&ほぼ必須な要素としてGitが存在します。
とはいえ、gitについて調べても「 commit や push みたいな基本操作は分かるけど、深いところが何も分からん……」となりがちではないでしょうか？

このトークでは、ベテランエンジニアはなぜか知っている git 知識についてお話ししようと思います。

具体的な内容

git init した際に構成される.gitディレクトリの中身について
GitHub上にあるgit/gitのソースコードを覗いてみる
実際にgit addとgit commitをPHPで実装してみる

対象者

• 簡単なgitコマンドは扱える人(add, commitなど)
• 複雑な操作になると不安になってしまう人
• あの日破壊したブランチのことをまだ忘れられない人

Fiber は、PHP 8.1 から導入された stackful な coroutine です。
ここで一度、Fiber の実装を PHP の処理系レベルまで追いかけることで、Fiber が何であるか、そして、裏で何をしているのかを理解することにしましょう。

主な対象

• 非同期処理の内部実装に興味があるかた
• 言語処理系の内部実装に興味があるかた

話すこと

• PHP における「Fiber」とは何か
• PHP の VM (virtual machine) のおおまかな構造
• Fiber を実行・停止・再開・中断したとき、PHP VM に何が起こるか

話さないこと

• Fiber を裏で利用するライブラリやフレームワーク

Garbage collection (GC) とは、確保したメモリ領域を適切なタイミングで解放する仕組みのことです。
メモリが比較的潤沢になった今でも、メモリ溢れによるサーバ障害は決して珍しくありません。
PHP における GC を理解し、メモリを意識したプログラミングをすることで、本番サーバを夜中に落とさないようにしましょう。

主な対象

• 普段メモリを意識してプログラミングしていないかた
• 言語処理系の内部実装に興味があるかた
• メモリ溢れで本番環境をダウンさせたことのあるかた

話すこと

• PHP における GC のアルゴリズム
• 確保したメモリはいつ解放されるのか
• メモリ溢れを起こさないプログラミング

話さないこと

• GC のパラメータをいじってチューニングする

私は新卒エンジニアとしてスクラムに関心を持ち、Certified ScrumMaster (CSM) 資格を取得しました。そして、大規模プロジェクトにおいて、先輩のスクラムマスターがスクラムを導入していく様子と、その変遷に携わった経験を通して得た知見を、このセッションで皆さんと共有したいと考えています。

初期段階では、職能ごとにチームが分割され、コミュニケーション不足と手戻りが増加しました。後に他のチームにエンジニア兼スクラムマスターがアサインされ、チームビルディング、振り返り、他チームとのコミュニケーションの機会が増え、プロジェクトにポジティブな変化が生まれ始めました。

このセッションでは、新卒エンジニア視点からの具体的な経験とスクラムの文化を持たないチームにおいて、緩やかなスクラム導入を支援するスクラムマスターの動きについてもお話しします。

2023年はコロナ禍から日常が戻り始め、様々なテックカンファレンスが開催されて、その楽しさや重要性を皆が再確認した年でした。それを受けて2024年は各地でPHPカンファレンスの開催が予定されています。

2018年と2019年に全国で開催されたPHPカンファレンスにおいて、紙の台紙を用いたスタンプラリー企画を私は実現しました。せっかくなので2024年もなにかやりたいのですが、台紙の用意やはんこの発注など面倒な作業が多いので、以前と同じ方法は取りたくありません。

そこでスタンプラリーをウェブサービスとして実装し、みなさんに使って頂くことにしました。PHPカンファレンス北海道2024はその初お披露目になる予定です。果たして快適に動作するのか、乞うご期待。発表ではその技術解説やインフラ構成についても話す予定です。

一番最初の技術選定をはじめとして、コーディング規約採否・静的解析採否・仕様・関数名・変数名などなど…開発の仕事は「決める」ことの連続です。
ここぞというときに素早く「決める」ためには、何が必要か？何をしているか？何を考えているか？
ベテランPHPerが日々実践していることをお話しします。

オブジェクト指向プログラミングにおいて重要な概念となる「SOLID原則」 。
本セッションでは、自分が違反して書いてしまったコードを例に、SOLID原則を紹介していきます。

• どのSOLID原則に違反しているか
• 違反がもたらす具体的な問題
• 正しい実装

多くの書籍でSOLID原則に関する具体例が示されていますが、このセッションでは「実際の失敗例」を通じてSOLID原則を理解していただこうと考えています。
自分がミスってしまった実装例を、時間の許す限り赤裸々に公開します！！

このトークでは、アプリケーションエンジニアとデータエンジニアとの連携を捗らせるアイデアを紹介します。
この内容は間接的にアプリケーション開発する上でも役立つテクニックになるはずです。

元PHPer現データエンジニアの目線で、
「こうやっておけばあとあと楽だった！」「このおかげでめっちゃ捗ってる！」「作る時にここを気にしてくれるとうれしい！」
といった内容をお話しさせていただきます。

【トーク例】
・自動でER図を生成！ SchemaSpy！
・賛否あり？ Enum値は文字列で保存してクレメンス
・データパイプラインが止まっちゃった！ XXする時は教えてくれ！

Composerは、デフォルトではPackagistというサービスからパッケージ情報の取得を行います。
Packagistのような役割を「Repository」と呼びます。

Repositoryについて知る事は、Composerが「何をするツールなのか」から踏み込んで「どう動いているのか」を理解する助けとなります。
「パッケージ検索やバージョン情報の管理・取得」「ライブラリのcomposer.jsonの意味」を把握できますし、「Composerと各サーバーとのやり取り」に関するライフサイクルも掴めます。

であれば！「Packagistみたいなものを自分で作ってみる」のは、良い学習材料になるのではないでしょうか！

このセッションでは、「PackagistみたいなRepositoryサーバーを構築してみる」をテーマとして、必要な概念・知識の説明とコードによる具体例の提供を行います。

組織、変えていますか！

組織の変化や組織変革を導く行動は、とてもよく研究されている分野です。入門書から専門書まで様々な出版された知見に触れることが出来ます。
裏を返せば、それは知識=プラクティスだけでは立ち行かない難しさの表れでもあります。
が、とにかく何かから始めていかなければ、何も始まらない訳です。
銀の弾が無いからこそ、まず「知ること」は武器になる筈です。

私自身は、エンジニア組織全体を扱うマネジメントに携わった立場や、そこに至る流れの中で、「人を巻き込む事」「組織の雰囲気や目先を変える事」に取り組む場面が多々ありました。
そうした経験から、このセッションでは、以下の3つのキーワードを中心に「変えていき方」を紹介します。

• 何事にも先立つのは「観察」から
• 説得ではなく納得、理解ではなく共感
• 組織・システムを動かすのではなく、自分の立ち位置を「ズラす」

PHPStanを入れる時の話です
既存のプロジェクト・・色々な歴史の重みを抱えるコードベース・・・さて、どうしますか？

よく「低めのLvから始め、教育と理解促進も図りながら徐々にLvを上げる」という手法が紹介されます
非常に健全で真っ当なやり方で、絶対良いです
が、皆さんの現場に於かれましては「そんなに忍耐強くやっていられぬ、いいからとっととやっちまいたい」という感情はないでしょうか？

このセッションは、そんな茨の道、ハードコアなスタイルを自ら選ぶように、”傲慢”・”短気”を包み隠さない人を応援します

ポイント

• 「現状に合わせて」ではなく「何を得たいか」から逆算すると、「まずLv0」は最適解なのか？
• baselineがデカい？そんなの関係ねぇ
• 誰もやらないなら自分で行く、という気持ちで既存コードをどうにかし続ける
• 少しでも気概を見せている人には全力で寄り添う

ここ数年、「(ラボラトリー方式の)体験学習」という概念と出会って、非常に面白いと感じているので紹介したいです
Webエンジニアやアジャイル(或いは志半ばの)チームにとって、学ぶ価値のある領域だと確信しています

例えば、ふりかえり。
「チームで集まって立ち止まる時間をとっている…しかし、次のアクションを出しはするのの、チームの考え方を変える様な気付きは生み出せていない！」
なんて事、ないでしょうか

生身の人間の集合である以上、議論には合理的で安定した判断以外も混ざります。どうしても人間関係や感情・感性が影響を持ちます
そうした内面的なもの・議論の中で言葉として表出され難いものをも含め、参加者同士で認め学び合うのが、体験学習の世界観です
それにより、いつもとは違う視点を引き出します

このセッションでは、体験学習のエッセンスに触れながら、チームの進化に向けたふりかえりの実現を考えていきます

privateメソッドのテストを書くか書かないか問題はよく話題にあがるかと思います。
実は、私もかつてはprivateメソッドのテストをたくさん書いていた時代がありましたが、今はprivateメソッドのテストは書かずにテストを書いています。
自分の思考の整理をするのに繋がった「単体テストの考え方/使い方」という本の内容からも引用しつつ、
実体験をベースに「なぜprivateメソッドのテストを書かないのか」というところをお話します！

トークで話す内容

• かつて私が書いていたprivateメソッドのテスト(と、その理由)
• なぜそれが良くなかったか？「偽陽性」「偽陰性」の視点から考える
• どのようにテストを書くべきだったか？
• privateメソッドのテストは書かない方がいいのか？(※経験に基づいた持論)

最近ではほとんど意識することなく文字でやり取りができていると思いますが、
例えば、時々何故か🙇と♂♀が分割してたり、「私の推しマークは🩵です、時々違う方がいます。気をつけてください」などと啓発しているアイドルさんだったりが居たりします。新しいiPhoneと古いスマートフォンなんかでよく起こったりするみたいですね。

これにはUnicodeがもちろん関係しています。
PHPはちゃんとUnicodeを扱えるのでしょうか？探ってみたいですよね？

本トークでは、PHPとUnicodeとの扱いについて追求していきたいと思います。

例外は投げるもの、そうおもっていませんか？

「PHPにおいて、例外は値である」

つまりは様々な事ができるはずである。先入観を捨てません？

ということで、禁書指定、あるいは私が糾弾されそうなトークをしてみたいと思います。

※ このトークは上級者・異端者向けです

platform.shを知っていますか？
platform.shはherokuやvercelのようなPaaSサービスです。Laravelも使っているSymfonyコンポーネントの作者であるfabpotも参画しており、PHPを動かすのにも最初から対応しています。
何ができるの？どう使うの？日本語対応してるの？料金いくらぐらい？
自腹を切って実際に使ってみた体験記をお話しします。

LaravelにはFacadeというものがあり、

DB::select('select 1');

というように利用することで処理を実行できます。
しかし、よくよく考えるとなぜこれが動くのか、きちんと理解して使っているでしょうか？

このLTでは「Facadeがなぜ動くのか」を理解したうえで、「Facadeは極力使うべきではない」という意見について、「なぜなのか？」を話したいと思います。

Laravel Breezeとgoogle2faを用いた設定を行うにあたってやったことを、実際に作ったものも踏まえてご紹介します。

システム開発を行う上で必ず存在するもの、それは組織です。
そして組織には人の出入りがつきものです。
しかし、入る人間よりも出る人間の方が多いと次第に組織運営は立ち行かなくなってしまいます。

このトークではなぜ人は組織から去っていくのか？を自身の経験＋書籍『エンジニアリングマネージャーの仕事』をもとに考察した結果をお話したいと思います。

具体的な内容

• 自身の経験に基づく、組織を去るときのマインド
• 書籍『エンジニアリングマネージャーの仕事』に基づいた、「エンジニアリングマネージャーが与えるべきもの」
• 自身の経験と書籍『エンジニアリングマネージャーの仕事』で語られる「人が去っていく理由」を照らし合わせた結果

対象者

• 現在進行形でエンジニアリングマネージャーの方
• 長く一緒に働いてくれる同僚を探している方
• 転職を考えている方