クロスプラットフォームアプリ開発フレームワークのReact Native(RN)はJavaScript(JS)でiOSとAndroidアプリを効率よく開発、早くリリースできるメリットがあります。
一方でPain Pointとしてはメンテナンス性の悪さがあり、RNのアップグレードにはiOS/Androidの設定ファイル（Info.plist/build.gradleなど）やコードの変更が必要で、さらにサードパーティのJSライブラリやネイティブモジュールの更新となると大変です。

Expoによって定義されたContinuous Native Generation(CNG)というコンセプトを取り入れることで、スケーラブルでメンテナンス性に優れたクロスプラットフォームアプリ開発が可能になります。
このトークではCNGの概要、CNGを取り入れたExpoアプリ開発プロセス、導入事例ついてお話します。

わたしは十数年間この業界にいますが、いろいろなサービス層を見てきました。

• DBの処理がごっそり書かれているサービス
• トランザクションスクリプトが詰まったサービス
• いろいろな場所から使われる神サービス
• たくさんのサービスで徒党を組んで仲良くしているサービス
• ドメインレイヤーにおけるサービス
• とりあえずサービス

可愛らしいサービスや憎きサービスがそこにはいました。
そしてこう思うのです「人には人それぞれのサービス層がある」と。

なぜ、人はみなそれぞれのサービス層を作ってやまないのか謎に迫りつつ、

• そもそもサービス層とはなにか
• どのような場面でサービスをつくるべきか
• 憎まれるサービス、愛されるサービスとはなにか
• 理想とするサービスの探求

について、SOLID原則、特にSRP（単一責任の原則）について言及しながらお話できればと思っています。

Rustは高いパフォーマンスとメモリ安全性を両立したプログラミング言語で、最近ではLinuxカーネルの開発に一部取り入れられたことでも話題になりました。

そのRustで、PHPの拡張モジュールを作ることができるのをご存知ですか？
拡張モジュールはC言語で開発されることが一般的ですが、ext-php-rsというライブラリを利用すると、Rustで書いたコードをPHP拡張モジュールとしてコンパイルすることが可能になります。

このセッションでは、Rust初心者であるPHPerの私がPSR-7のライブラリを題材に、以下のことをお話しします。

• Rustとはどんなプログラミング言語か
• PSR-7とは何か
• RustでのPHP拡張モジュールの作り方・デモ
• Rustを使ってみて感じたこと

最近のプロダクト開発においてSPAやマイクロサービスといったアーキテクチャを採用しているケースが多く、バックエンドのWeb APIの開発を避けて通れないと思います。

登壇者も近年数多くのAPIの開発を行ってきました。その中でスキーマ駆動開発も取り入れた開発プロセスを取り入れるなど、APIのスキーマ定義・管理方法ついて試行錯誤を重ねてきました。

その中でAPIのスキーマのバージョン管理がコラボレーションを行う上で大変重要であると気づきました。

如何にAPI開発側及び利用者双方の運用負荷を増やさない開発プロセスを考えることが大事です。

• APIのバージョン管理
• API仕様書の静的チェック
• API仕様書を活用してアプリ全体の品質向上
• 仕様書以外でのバージョンの活用
• 円滑なリリースマネジメント

等など、CI/CDまで踏み込んだ実践してきた内容をご紹介いたします。

株式会社ウィルゲートで、24新卒エンジニア向けに「エンジニア基礎」という研修を実施しました。
今回、社内で新卒エンジニアやベテランエンジニアからも大好評だった研修を、PHPカンファレンス福岡で特別に再構成して皆さんにお届けします！

バックエンドやフロントエンドの知識といったテクニカルスキルの習得よりも、エンジニアとして重要なのは、 成長していくために必要なスタンスやマインドについて知ること です。

このトークでは、2時間の研修から特に重要なポイントに絞ってお話します！

話すこと

• なぜエンジニアとして成長するために「スタンス・マインド」が大事なのか
• エンジニアとしての基本心構え「プロ意識」
• コミュニケーションの心構え
• キャッチアップスキル
• 作業するとき全般大事なこと
• コード書くとき全般大事なこと
• 継続的な成長をするために

私は現在VPoEとして、開発メンバー18人の1on1を毎週行っており、マネージャー時代も含めて3年以上メンバーとの1on1を続けてきました。

その中で、急成長する人は、1on1の使い方、上司の活用方法が圧倒的にうまいことに気づきました。

本セッションでは、VPoEの視点から様々なタイプの1on1を通して得た、急成長する人の1on1の特徴をまとめ、それを実践するための方法について話します。

こんな人におすすめ

• 1on1はしているけど、いまいち成長実感がわかない
• 1on1で何を話し、どう成長に繋げればよいかわからない
• なぜ1on1をするのかよくわからない
• 圧倒的に急成長していきたい人

私はこれまでにPHPを全く書いたことがありませんでした。そんな私がPHPerKaigi 2024に参加しようと考え、せっかくだからLaravelで簡単なWebアプリを書いてみようと考えました。
RubyとRailsのエコシステムにどっぷりな開発者が、PHPそしてLaravelに入門して感じたことを話します。

そしてここからがこの発表の本題ですが、プログラミング言語またはフレームワークのコミュニティに新規参加者を増やすにはどうすればいいでしょうか。PHPerKaigiの懇親会で出会った、Rubyを学び始めたばかりの方からの意見など様々な方と話して考えたことを話します。

このトークでは、「このようなことができるかもしれない」というアイデアを投げかけることが限界でしょう。このトークを聞いた皆さんからも意見をもらえると嬉しいですし、あとでゆっくり考えてもらっても嬉しいです。

2、3ヶ月程度かかる大きめの機能開発も任されるようになったとき、「設計をどのようにすればいいか分からない」「大きい変更のタスク分割が難しい」と悩むことがあると思います。
全体の機能を一度にまるっと作ってからリリースしようとすると、プルリクエストが肥大化しレビューが複雑になり、見落とされた不具合や障害が発生しやすくなってしまいます。

このトークは、その悩みを解決する具体的なテクニックを、設計やタスク分割に慣れていない方に向けて順を追って説明します！

話すこと

• なぜ、デプロイ頻度が大事なのか？
• 細かくデプロイするためにインタフェースを設計しよう
• 安心して実装に取り組めるように、テストコードを先に書こう
• インタフェースごとにタスクを分割して実装しよう

-- 〇〇さん、次このプロジェクトに参画して開発してください
私は初めてプロジェクトに参画することになった。
-- 〇〇さん、進捗はどうですか？
進捗を聞かれてもいつでも答えられる。
-- 〇〇さん、作業終わったみたいだから次この機能開発してくれる？
開発タスクも順調にこなしてるし、よくわからないけどプロジェクトのマイルストンも順調に進捗してるらしい。

「あれ？でも、この機能って前にやった機能といっしょに開発したほうが早かったな。それにあのカンファレンスで聞いた〇〇って技術でもっといい感じにできたかもな。」
「でもテックリードでもPMでもないし、機会が回ってきたときでいっか。」

本当にそれでよかったのでしょうか？
このセッションでは、メンバー目線での情報がプロジェクトにとっていかに重要か、メンバーでもプロジェクトにもっと貢献するテクニックを話します。

日時はクライアント、サーバ、データベースといった要素間で「旅」をします。
また、ある日付から1ヶ月後や2年前といった計算には、想像以上に多くの考慮が必要です。
本トークでは、それぞれの要素での日時の安全な扱い方を具体例と共に解説します。

話すこと:

• タイムゾーンにおける問題と解決策（DBはPostgreSQLを中心に）
• SPAでの日時のクライアントとサーバ間通信
• PHPで実装された「危ない」日時操作を「安全な」日時操作に置き換える方法
  • 例に出すコードの問題点と解決策
  • date()からDateTimeクラスへの移行など
• これらのテスト方法

ターゲット:

• 日時操作をコピペしている方
• 文字列操作で日付を生成している方
• より良い日時を扱うの方法を学びたい方

うるう年のこの機会に一緒に日時の扱いを見直して、安全な操作方法を学びましょう。

さる3/9、PHPerkaigiで行った「BEAR.Sundayの分散キャッシングフレームワーク」の講演に、「映画のようだった」「とてつもない伝説」など、聴衆の心を動かしたような感想が寄せられました。

本講演ではこの講演の舞台裏をメイキング形式で語ります。元のスライドを用いて、技術的課題への取り組みが普遍的な問いかけと開発者の情熱につながる道のりを紹介。松尾芭蕉の思想、多くの伏線、比喩や例え話、映画的構成、言葉選びの工夫、AIの活用など、創作の裏側を交えながら、開発者として私たちが何のために何のシステムを作っているのか、その本質を問います。

障害対応において

• 調査する人
• 連絡する人
• 見守る人
  だけになってしまっていませんか？

一つ上の視点に立ってみると、それらを統括する「インシデントコマンダー」という役割があります。
この「インシデントコマンダー」とはどんなことをしている人なのか、どんなことを考えているのか。
そんなお話をしていこうとおもいます。

お話すること

インシデント対応における統括する側の考え方や視点
私がインシデント対応において大切にしてること

ターゲット層

インシデント対応をしている若手エンジニア

皆さん、php-src （PHP 処理系のコード）読んでますか？

PHP 処理系は C 言語で書かれたプログラムであり、多くの大規模 C プロジェクトと同様にプロジェクト固有のマクロが広く使われています。言語処理系のコードというもの自体が読むのに前提知識を要するのもあり、学校で少し C を習ったことがあるくらいの人だと、読みこなすのはけっこう骨が折れます。

しかし PHP で仕事をしていく中、処理系実装を追えると簡単に解ける疑問、原因究明が楽になるトラブルシュートは案外多いです。全員といわずとも、10 人くらいのチームごと 1 人でも読める人がいれば助かる日は多いことでしょう。

このトークでは PHP スクリプトに書かれた文字列リテラル 'hello world' が処理系に読み込まれコンパイル・実行され出力バッファや SAPI 層を通りぼくらの画面へ届くまで、を駆け足で解説します。

情報技術の発展や市井への広がりを話す上で，コミュニティの存在は欠かすことのできない要素です．
我々の触れられるコミュニティは，偶然に栄枯盛衰を経て，今，活動を観測できるコミュニティのみです．
　
かつて終わりを迎えたコミュニティの全てが大団円とは限りません．
目的を果たし，構成員の意思で終わりを迎えられたコミュニティは，恵まれていたと言って差し支えないでしょう．
　
このセッションでは，どのようにしてコミュニティが求心力を失い，”技術” コミュニティとして機能しなくなってゆくのか，コミュニティを愛すためにどう振る舞うか，話者の体験を交えてお話しします．
　
【話の流れ】

• 関わる人々の心構えによる分類
• 技術コミュニティに期待する機能による分類
• 技術コミュニティに向けられた愛による分類
• 全てを重ね合わせた先にある捩れ
• 我々は多様なコミュニティの在り方を認められるのか

サーバーレスPHP、聞いたことがあるけど具体的にどのように進めれば良いかわからないという事は有りませんか
今回はAWS LambdaにてBrefを使用する、サーバーレスPHPに関するトークを行います

その中でAmazon SQSを使用したメッセージングシステムの統合、さらにTiDB ServerlessによるDBaaSの統合を行った
実際に利用の検討が出来るアプリケーションをソースコードを添えて解説します
また利用されている様子がないとイメージが難しいと思うので、デモも合わせて行います

コードとデモの側面からサーバーレスPHPの可能性に触れていただき、
皆様がサーバーレスPHPを始める為の参考になれば幸いです

• 想定する聴講者
  • サーバーレスPHPのはじめ方は知っている方
  • サーバーレスPHPの実際のソースコードが見たい方
  • サーバーレスPHPの動作を見たい方

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しいのですが近年のコンピュータの高速化はすべてキャッシュによるものと言っても過言ではないぐらいキャッシュは重要な技術です。

このトークでは「なぜキャッシュメモリは速いのか」の説明から、なぜキャッシュが必須の存在なのか、そしてキャッシュが引き起こすCPUの脆弱性について初心者の方にもわかりやすくご説明します。

コンピュータアーキテクチャの勉強、というよりはキャッシュを取り巻くハートウォーミングストーリーを聴きに来るつもりでいらしてください。きっと「CPU脆弱性って言っても思ったより難しくないな」「おもしろいな」と思って頂けると思います。

株式会社キャッチアップ（ https://catchup.co.jp/ ）の取締役をやっております。
入社後3〜5年ごろに教えてもらったのですが、入社前での面接時にはポテンシャルや期待がほとんどなかったとのことを知りました。そんな私が新米エンジニアとして入社してから今までどんな問題にぶつかってどのように考え、このようなキャリアに至るのかをお話します。私の経験談がIT業界の若手のみなさんに気づきや勇気を与えられるきっかけとなれば本望です。

皆さんは情報設計という言葉を知っていますか？ 情報設計は、UXデザインの5段階モデルの中の中間層である「構造」の中でよく出てきます。

弁護士ドットコムでは、情報設計をUXという世界を超えて、より堅牢なWebサービスをみんなで作るために情報設計に向き合う取り組みを始めました。

社内では様々な職種に広めるために、1年間に渡って勉強会を実施してきました。それだけでなく、私が所属するチームでは実際のプロダクト開発にも導入しました。

本トークでは社内で行ったワークショップの紹介や、実際の導入事例を紹介することで、より堅牢で長くWebサービスを提供する方法を皆さんにお話しします。

最近はOpenAPIを利用したスキーマ駆動開発のお話をカンファレンスや勉強会などで聞く機会が増えてきました。
スキーマ駆動開発で利用されるOpenAPIの定義は、手書き派の方が多い印象ですが私はyamlの手書きがとても苦手です。

本セッションでは、以前から利用しているswagger-phpを利用したAPI仕様の実際の書き方から、OpenAPIを活用してどのような形で開発を進めているかをお話ししようと思います

話すこと
swagger-phpを使ったAPI仕様の書き方
OpenAPIを利用したスキーマ駆動開発の進め方
フロントアプリとOpenAPI定義を共有する方法

私がCIの書籍を執筆した2014年当時はまだCI/CDはそれほど普及してはいませんでした。10年の時が流れて、現在開発の現場でCI/CDパイプラインは当たり前のように利用されています。

皆さんの開発現場でもなんらかの形でCI/CDを活用していること思います。しかし、利用するのが当たり前になったためか、以前より様々な開発の現場でどのような形で何をやっているか？のような情報があまり出てこなくなったなーと感じています。

本セッションでは、10年前のCIの実行環境などを振り返りつつ、私が現在構築しているCI/CDパイプラインの内容について解説をしたいと思います。

話すこと
過去のCI環境の簡単な振り返り
私が現在運用しているのCI/CD環境とどんなことをしているか