トーク

カンファレンスに参加した！
参加するまではドキドキでも終わってみたら楽しかったな！と感じるのではないでしょうか？？

ただ、みなさんからいただいた熱量をもって明日以降に活かすぞ！と意気込むのですが、何からやっていけばいいのかな…と悩んでしまうこともあると思います。（カンファレンスなどに参加したてのわたしもそう思っていました…）

でも、ほんの少しのアクションをするだけでも明日以降のモチベーションや次回以降の参加につながる！と最近は思っています。（本当にささいなアクションでよいのです！）

本トークではわたしが実践しているささいなアクションを紹介しつつ、「今日は楽しかった！」と感じていただいた方が明日から先にも続いていくカンファレンス人生をより楽しんでいただくためのヒント（になって欲しいこと）をお伝えしたいと思っています！

開発時に厄介なのはバリエーション。
PHPerは日々フレームワークごとの違い・バージョンごとの違い・データベースの違い・クラウドインフラの違いといった純粋に技術的なバリエーションに悩むこともあれば、複数の異なる配送業者・複数の異なるAPI接続先・複数の異なる計算方式といった要求・要件のバリエーションにも悩んでいることでしょう。
このバリエーションへの対処法を整えることでエンジニアとして強くなる方法をお話します。

依存パッケージの更新はしていますか？？

小さくコツコツ手をつけておけばよかった…そんな気持ちになることもあるかもしれません。。
日々降ってくる、マイナーバージョン・パッチバージョンの更新を適応するのは大事です。

メジャーバージョンがあった場合はどうでしょう？？
依存パッケージ間の依存関係があるなど、マイナーバージョン・パッチバージョンの更新と比較して、複数のパッケージの同時更新が必要だったりもします。Renovateがプルリクエストを出してきたが、エラーになってそのままマージにならない…なんてこともあったりします。

本トークではパッケージを更新するコマンドであるcomposer updateをおさらいしつつ、何ができるか？何が起こるか？を確認しながら、今一度パッケージのバージョンアップについての手順やはまりポイントについてお話ししたいと思っています。

今までバッチ処理について雰囲気でやってきていませんか？僕は少なくとも雰囲気でやってきました。
もちろんバッチ処理なしで実装できるに越したことはありませんが、運用としてすでにそうなっているところも多いのではないでしょうか？
実際そんなに困ることねーし・・・！とそう思っていたそのとき！困る時がやってきます・・・。(震え声)
基本的にバッチ処理を避けた方が良いパターンについて言及しつつ、バッチ処理が必要な際にどのようなことを考えれば良いのか？どう見直す道筋を立てるのか？
TechTrainで実装するときに失敗したな・・・。と思った経験を踏まえてお話しします。

対象者

1. すでにバッチ処理があるが、どう見直したら良いのかわからない方
2. なんかバッチ処理でいけそう！と初手で考えてしまう方
3. バッチ処理書いてみたんだけど、良いのかわからない方

みなさんご存知のように、2024年は毎月PHPイベントが開催されるほどPHPコミュニティが活況を呈しています。私はそれに合わせて、2019年以来久々に「日本PHPカンファレンススタンプラリー2024」を実施しています。今年は台紙とスタンプという物理媒体ではなく、ウェブサービスとして電子的なスタンプラリーを実装し、それに関する発表もPHPカンファレンス北海道2024で行いました。その際の実装はPoC的なものでしたが、福岡ではおそらく本サービス実装になっていると思われます。本LTではその本番実装についてと、それまでのスタンプラリーの利用具合について発表します。

この世の中には、何かを決定する機会がとても多いです。
例えばサービスのある仕様を決める時、例えば技術選定をする時、例えば設計で悩んでいる時・・・

そんな時、たった一つのシンプルなルールとして、「何かを決める時は、より質良く / より多く理由を言える方が良い」を提案したいと思います。
このLTではそのルールについての解説や、具体例について話していきます。

このLTで話すこと

• 様々な視点・視野・視座からものを考えた結果として、より質良く / より多く理由を言えるようになる
• どれだけより質良く / より多く理由を言えるかと意思決定のスピードを両立するには、あれこれ試して振り返る学習ループを地道に回すしかない

Docker の登場で、開発環境の構築はとても容易になりました。
コンテナを利用することで、実行環境の差異を隠蔽できるほか、複数の異なるバージョンの環境を 1つのマシン内で実現することもできます。

一方で、実際に PHP 製のアプリケーションを Web サーバー上で動かす際には、動作環境についての理解が必要です。
特に、フレームワークを利用したアプリケーションが、手元では動作するのにデプロイ先で 500 エラーを返す、といった経験はないでしょうか?

本トークでは、 PHP の動作環境を一から構築する方法についてお話しします。
PHP の本体だけでなく、 Web サーバーやデータベースといった、 Web アプリケーションを動かす上で必要不可欠な要素についてもお話しします。

手軽に動作環境を構築できるようになった今だからこそ、あえて PHP の動作環境を自分で構築してみませんか?

PHP書き初めて半年経っていない初心者が、爆速と噂（要出典）のphalconでWEBアプリケーションを作った所感について話します。
Larabelや他フレームワークとの比較をしつつ、果たして開発で使うべきなのか、初心者に優しいのかというような観点から、
個人の独断と偏見を元に、５分間という短い時間の中を爆速で紹介していきます。

私は首都圏企業の札幌開発拠点のエンジニアとして働いており、弊社では定期的に札幌市内でエンジニア向けのイベントを開催しています。

イベントで学生や初学者の方々と交流する中で、
「エンジニアを目指していく上でどんなことを学べば良いのか」「実際の開発の現場ではどのようなことをしているのか」
という情報を特に地方都市では得る機会が少ないと感じました。

少しでもきっかけになればと思い、「Laravelを用いて勤怠管理システムを作成する」というお題で、要件の検討や設計も実施するソフトウェア開発を体験いただくハンズオンを開催し
道内の学生や初学者の方計10名に参加いただきました。

本セッションではイベントを通して自身が気づいたことと経験、エンジニアを目指す人々がどんなことを気にしているのか
そして地方都市でこそもっとハンズオンイベントを開催した方が良い理由をお話しします。

プログラミングの学習をして、開発経験を重ねて……
しかしながら「一人や少人数で行う個人的な開発」と「実務として行うお客様のためのシステム開発」には大きな違いがあります。
前者にはなくて後者にはあるものとは何でしょうか？
私たちは誰のために、何のためにコードを書いているのでしょうか？

システム構築〜保守・運用まで全て自社内で一貫して行う会社に異業種からエンジニアとして転職し、初めてシステム開発案件に参画して痛感した「実務経験」の話をします。

きっと今の私にしか話せない内容です。この先も大切にしたい”今だからこそ得られる気づき”をお話できればと思います。

【話すこと（予定）】
初めての案件で痛感した、実務におけるコードの書き方・開発の考え方
コードはコミュニケーションだという話

【隠れ目的】
実務経験をさらに重ねているであろう未来の私がこのLTを思い出して大切な初心を思い出せること

「アジャイルなんてオシャレな自社開発企業だけの特権でしょ？」

そう思っていた時期が自分にもありました。アジャイルを実践した今となっては、アジャイルはチーム単位や、ひとりからでも始められる！と確信しています。

このセッションでは、アジャイルの魅力、そして始め方についてお話しします。

こんな人に聞いて欲しい

• アジャイルのことは知っているけど、まだ実践できていない人
• 受託開発だからアジャイルは無理、とあきらめてしまっている人

お話すること

• アジャイルのはじめかた

お話しないこと

• アジャイルにまつわる開発手法

PHP 8.1 で readonly property、そして PHP 8.2 で readonly class がサポートされるようになりました。

近年様々な言語でサポートされることが増えた「不変」であることが保証された変数やクラス。
PHP でもこれらの機能がサポートされたことで、中〜大規模なアプリケーションにおいて、バグを生みにくく、保守しやすい「堅牢」なコードを書けるようになりつつあります。

本トークでは readonly class を使う理由、そして実際に使って日々開発をする中で得たリアルな知見をお伝えしたいと思います。

話すこと

• readonly class とは
• readonly class を使う理由
• readonly class を使う場合の辛さ

※ PHP Conference 2023 でお話した内容をアップデートしたものです。

GitHub Enterprise には、自社サーバにインストールして利用する GitHub Enterprise Server (GHES) と GitHub Enterprise Cloud (GHEC) があります。
会社によっては、自社のサーバでデータを保持したい等の理由で GHES を使用していると思います。

サイボウズの Garoon 開発チームでも GHES で開発を進めてきましたが、最近その負荷が高まっており、運用の限界が見えていました。
そのため、リポジトリを github.com (GitHub Enterprise Cloud) に移行しています。

しかしながら、100 人規模のチームで利用しており、ほぼ毎日のリリースへの影響もあるため、移行はなるべく開発を止めずに行う必要があります。
このセッションではそのためにやったことや移行時の困りごとなどを共有します。

柔軟に小さく作る。言葉は簡単だが、実際には難しいところである。
顧客の欲しいものは本当のところ顧客自身もわかっていないことも多々ある。

我々も顧客に寄り添って価値を想像するために、小さく決めて開発をする必要が出てきた。

しかし時には、小さく作ることが開発チームのエゴになるときもありうる。顧客だけでなくチームとしてどの単位が最小価値なのか、悩まれる方も多いのではないだろうか。

小さな、動くものが正義。嘘か真か、顧客や世の中に問いながら細かく作り、大きな決定を遅らせる開発手法を紹介しようと思う。

話すこと

• 決めなきゃいけないことだけ、決断を刻む
• 松・竹・梅で三点見積もり
• インタフェースで区切った決定駆動開発

eBPF（いいBPF、あるいはよかBPF）はLinuxの最先端技術の一つです。具体的用途として、ネットワークパケットのフィルターやフォワーディング、可観測性ツール、セキュリティ関係のツールの内部で利用されています。

eBPFはLinuxの謎技術なので一見難しそうですが、実は簡単な内容なら、C言語風DSLのパターンとPythonやRubyなどLLの若干の知識だけで、問題なく使えます。bpftraceという簡単に使えるコマンドツールも存在し、PHPのアプリ改善にも活用できるのです！

今回のトークでは、まず、PHPのためのeBPFの概要と、その周辺技術やツールなどを紹介します。その後、PHPと関連ミドルウェアを題材に、eBPFを使ってみましょう。例えばPHPの友達Apacheの計測であったり、PHP自体のアプリケーションprobeを利用した例をデモします。

PHPerKaigiでは、タイムゾーンの雰囲気実装を抜け出すための話をしましたが、タイムゾーンは政治的な理由でよく変更されたり、tz databaseの過去の設定が実は間違っているなんてことが実はあります。実際に変更された時に僕たち実装する人がどう対応していかなければならないのか？危ないケースはないのか？について、お伝えします。

どの企業でもPHPerのミドルクラス、テックリードクラスの採用とオンボーディングには苦労されていることと思います。特にオンボーディングにおいては、別言語をメインでやっていた方を採用し、活躍してもらうためにはこのくらいはキャッチアップできるだろうし、大丈夫！というサボりが、認知負荷を高め、活躍までのリードタイムを長くしたり、副業エンジニアの離職を招きます。このトークでは、実際にTechTrainの開発現場で行なっているオンボーディングを出来る限り見せながら、一般的に利用できる形式にしてお伝えします。

対象者

1. テックリードを採用したものの、活躍してもらうために必要なことに悩むEM
2. 初めて業務委託エンジニアを採用した1人目エンジニア
3. マネジメント経験がないが、任されたスモールチームのテックリード

文法のミスからビジネスロジックの違反など、コードを書くうえでは様々な例外が発生します。

本セッションでは、例外処理の機能であるカスタム例外を活用することで、
コードの責務を明確にし、より理解しやすく保守しやすいアプリケーションを構築する方法を紹介します。

こんな方にオススメ:

• カスタム例外の使い所を知りたい
• どの例外をcatchすべきか知りたい
• 例外を使ったテストコードの書き方を知りたい

主に話すこと:

• カスタム例外の効果的な定義と使い方
• カスタム例外を使ったテストコードの書き方
• どこで例外をthrowしてcatchすべきか

PHPerなら誰しも通ったことのある（？）オレオレフレームワーク作り
ルーティングやDIコンテナのライブラリをcomposer requireすることでオレオレフレームワークを作ることは簡単ですが、今回はあえて（四角い？）車輪の再発明をすることで、普段皆さんが使っているであろうフレームワークやそのコンポーネントがどんなことをやっているのか？を掘り下げていきます

このトークを聞いて欲しい人

• Laravelでコンストラクタやメソッドにクラス名書くといい感じに解決される仕組みが説明できない人
• オレオレフレームワークを作ったことがない人
• PHPで何か作ってみたいけど何作ったらいいかわからない人

このトークの目指すところ

一般的なFWがどのようにルーティングとコントローラーを繋げているか雰囲気をつかめた！

皆さんはPHPerでしょうか？
なぜPHPerを続けているのでしょうか？

このトークではある日突然職種も業種も変えることになった私が「なぜPHPerになることを選択したのか？」と、「なぜ今もPHPerを続けているのか？」という観点からPHPとそれを取り巻くコミュニティの良さについてお話したいと思います

お話する内容

• 非PHPerだった私からみたPHPのイメージ
• 実際にPHPerになってからのPHPのイメージ
• PHPerコミュニティの良さ

想定聴講者

• 比較的最近PHPerになった人
• PHPコミュニティに入ってきて日が浅い人
• PHPとそのコミュニティに対する愛について話せる仲間が欲しい人