プロポーザル

Webプログラミングに欠かせない「正規表現」。でも、なんとなく 「怖い」「よくわからない」 と思っていませんか？
本セッションでは、業務で出そうな易しめの問題から、書いたら地雷なアンチパターン問題まで、全5問のクイズ形式で楽しく学びます！

動機:

1. 正規表現のシンプルな仕組みを伝えたい
2. 「魔法の道具」ではないことを実感してほしい
   • 通常の言語と「同様に」、関心を詰めこめば、それだけメンテナンスが厳しくなる
3. 複雑な正規表現を避けるための現実的な方法を紹介したい
   • 過去の発表で紹介した内容 (https://zenn.dev/shundeveloper/articles/e6405c323c555a) やライブラリなど

対象者:

1. 正規表現が「なんとなく怖い」プログラマー -> 楽しく学びを提供します！
2. 正規表現が大好きなツワモノ -> 目指せ全問正解!!

参照：

• https://zenn.dev/shundeveloper/articles/e6405c323c555a
• https://zenn.dev/shundeveloper/articles/8f74aa69ed9702
• https://zenn.dev/shundeveloper/articles/b5cc85b4d1e7eb

カンファレンスで今まで知らなかったことやテクニックを学ぶことは多いと思います。その中には下記を感じることはありませんか？

• 実際の業務にどう活用していけばいいのかわからない
• すごくいい発表だったけど、自分のチームに導入することができない
• その時はわかった気がしたが、実際に直面したら活用できなかった

私自身も最初は上記のことがあり、カンファレンスに行く必要があるのだろうかと悩んだ時がありました。
カンファレンスに行き初めて3年と短くはありますが、知識から経験にするために、大事にしている考えを共有できればと思います。

皆さんもここ数年、会社のいたるところで「自動化」を聞きますよね。
必ずと言ってもいいほど、「こういった処理を自動化したいんだけど、詳しいだろうからやってくれない？」みたいなこと起きませんか？
（場合によっては、「なんか動かないから直して！！」もあると思います）

ただし、言われたものをそのまま「自動化」をすると、「思ってたのと違う」「実はこういうことがしたかったんだよね」「コストかかりすぎない？」となることも多いと思います。

本トークでは、実際にあった「自動化」の例を取り上げながら、考えるべきこと、ヒアリングの仕方などを話していきます。

対象の読者

• よく事業部・営業部などに依頼をされることがある人
• 社内にあるあるフローを自動化をしたいと考えている人

プログラミング技術はこの長い歴史の中、Webではいろんな業種のナレッジが共有をされてきました。その中の一つに「共通化」を行い、「車輪の再開発をやめる」や「認知負荷を下げる」といったこと目的で取り組みするのをいたるところで聞きます。

ただし、「共通化」をすることで数年後に見るも無残な姿となり、逆にプロダクトの成長を抑制してしまったり、認知負荷を上げてしまうことがよくあります。

今回筆者が考える、プログラミングで考えるべき「共通化」の考えを中心に、過去経験したアンチパターンを元に話ができればと思います。

対象の聴講者は下記となります。

・プログラミング初心者
・悪い「共通化」がいたるところで見えるけど、どう伝えようか悩んでいる人
・失敗談を聞きたい人

多くのPHPプロジェクトで、知らず知らずのうちに技術的負債が溜まっていませんか？機能追加のたびに修正箇所が広範囲に及び、テストもままならない……。その原因の一つは、オブジェクト指向設計の基礎である SOLID 原則への理解不足や誤解にあるかもしれません。

SOLID 原則はソフトウェア開発において高品質で保守性の高いコードを書くための重要なガイドラインですが、やたら難しい言葉が並んでいるせいで理解が難しかったり、誤解が広まってしまっている面があります。

本トークでは、SOLID 原則に含まれる5つの原則について、アンチパターンやPHP での実践的な例を交えながら解説し、その活用方法や得られるメリットについてお話しします。このトークを聞けば、あなたはSOLID原則を「開発を楽にする武器」として捉えられるようになり、より変更に強く、テストしやすい、自信を持てるPHPコードを書くための第一歩を踏み出せるはずです。

こんな人に向けて話します

• SOLID 原則？何それ知らないよ！って人
• SOLID 原則、聞いたことあるけどよくわからん、って人
• SOLID 原則、完全に理解したけど実践できていない人
• SOLID 原則、理解しているけどどこまでやればいいのか悩んでいる人

自動ユニットテスト、書いていますか？

自動ユニットテストがコードの品質や変更容易性を向上させ、高い開発生産性の実現に寄与することは、もはやソフトウェア開発における共通認識と言えるでしょう。

しかし「どうやって書けばいいかわからない」から脱却できず、自動テストの導入に二の足を踏んでいる現場は未だに多く存在するようです。また「テストを導入した・している」という事実だけで満足してしまい、書いたテストが必ずしも効果を発揮していない、あるいは逆に開発の足かせになっている現場は後を絶たず、「テストは書いているけれど、逆に手間が増えてしまっている」「テストコードが増えすぎて保守が大変になった」といった声を聞くことは珍しくありません。

本トークでは、効果的な自動ユニットテストを書くための考え方やテクニックを、具体例やアンチパターンを通じてわかりやすく解説します。また、動的型付インタープリタ言語である PHP ならではの事情を交えながら、現場ですぐに役立つ知見を共有します。

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

• どうやってテストコードを書けばいいかわからず、導入に踏み切れていない人
• テストコードを書くのが「面倒くさい」「運用が大変」と感じている人
• 自動ユニットテストを書いているが、「これで正しいのか？」と不安がある人
• 良いテストコードを書く技術を身につけて、組織やチーム文化を改善したい人

お話しすること

• 効果的な自動ユニットテストを書くための基本的な考え方とテクニック
• よくあるアンチパターンと処方箋

お話ししないこと

• 自動テスト導入そのもののメリット
• 特定のツールやライブラリ、フレームワークの詳細な使い方
• インテグレーションテストやE2Eテスト、全体のテスト戦略について

ここ数年、私はRaspberry PiでCPUを作っています。
これは、Z80というCPUをコンピュータから取り外して代わりにRaspberry Piで作った自作CPUを取り付けて動かすというものです。

このトークでは私が作成した2つのバージョンのCPUを題材に、以下の様なことをお話します。

• 少ないGPIOで多くの信号線をコントロールする工夫
• CPUを作るというのは具体的に何をするのか
• 手配線で作るCPUと基板発注して作るCPU
• 自作CPUのデバッグ方法
• Linux上でプログラムを動かすことのメリットとデメリット
• 全てを手放して速度を得る - ベアメタル開発

このトークを聞いた方が「CPUを作るというのはどういうことか」をちょっぴり理解し、CPUやハードウェア自作が好きになることを願っています。そしてあわよくば一緒に自作CPUを楽しみましょう！

ここ数年、Raspberry PiでCPUを作っています。
これは、CPUをコンピュータから取り外して代わりに自作CPUを取り付けて動かすというもので、オリジナルのCPUの名前のZ80にちなんでPiZ80と呼んでいます。

PiZ80はZ80採用のパソコン・MSXをあわよくば高速に動かすことを目標にしています。
現在のPiZ80はMSXと同じZ80採用のシングルボードコンピュータ・SBCZ80でZ80よりも高速に動作する様になっていますが、ここに至るまでにはさまざまな改善がありました。

このトークではCPUを作るというのはどういうことか、CPUを作る時にどこに速度的な課題があるのか、そしてMSXでPiZ80を動かすまでの道のりをお話します。

このトークを聞いた方がCPUやハードウェア自作が好きになり、そしてあわよくばPiZ80のソフトウェアをいっしょに改善していけることを願っています！

CPUやプログラムの実行といったコンピュータの"低レイヤ"を知るためにCコンパイラを作成するのはとても良いアイデアです。
Rui Ueyamaさんの「低レイヤを知りたい人のためのCコンパイラ作成入門」はまさにそんな目的で書かれていて、手順どおりに進めていくだけで演算、変数、関数やポインタなど十分にそれっぽいCコンパイラを作れます。
ですが、このドキュメント、C（言語）でCコンパイラを作っていて、それ自体はごく普通のことですがPHPerにとっては若干ハードルが高いんですよね…。
OK。それならPHPでやってみましょう。
このトークではRui Ueyamaさんのドキュメントに従いながらPHPでCコンパイラを作る方法を解説します。
このトークを聞いた方がご自身でもPHPでCコンパイラを作成し、コンピュータの低レイヤを楽しめる様になることを願っています。

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

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

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

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しく、X（Twitter）ではいろいろな回答がされていました。この回答はさまざまな立場・理解からされていて、Xのタイムラインをご覧になっていた方はいまいちしっくりこなかったのではないでしょうか。

このトークでは「なぜキャッシュメモリは速いのか」に答えるのに必要な知識を、初心者の方にもわかりやすくご説明します。

• キャッシュメモリとは何か
• なぜキャッシュメモリを使用するのか
• キャッシュメモリとメインメモリは何が違うのか
• 結局なぜキャッシュメモリは速いのか

キャッシュの使いこなしは現代コンピュータにおいて避けることはできず、キャッシュを制するもののみがコンピュータを高速に動作させられると言っても過言ではない状態です。キャッシュを理解し、キャッシュを楽しみましょう！

毎年行っており初心者向けのセッションです！内容は毎年アップデートしております。

【対象】　PHP・プログラミング未経験者、デザイナー、途中で挫折した学習者、非エンジニア

【ゴール】　ChatGPTなどAIを“相棒”に自走学習できる。

【概要】

1. PHPとは ─ Webの大半を支え続ける実態と最新動向をデータで示し、「もう古い」という誤解を払拭。
2. PHPの環境 ─ ローカル環境からクラウドまで様々な環境での利用を紹介。
3. AIと連携したPHP基礎 ─ PHPの簡単な基礎からChatGPT などを用いた学習計画・サポート、VsCode,Cursorなどでのコーディングの仕方など。
4. PHPで動くプログラム ─ 簡単なプログラムをAIを使いつつ、何を考えるべきかを共有します。

セッション後、参加者は「まずは VS Code を開き、ChatGPT に相談しながら最初の PHP スクリプトを動かす」自信と手順を持ち帰れます。

皆さんは、インプットだけでなく、記事を書いたり、LTをしたりといったアウトプットをしていますか？僕は、1年前Qiitaに記事を投稿し始めるまではほとんどアウトプットをしていませんでした。

そんな僕が、去年の2月からQiitaに毎日記事を投稿し始め、約1年でなんと160記事を公開しました。
テーマは主にPHPやReactなど、日々の学びや実践で得た知見です。

「アウトプット経験ゼロ」からスタートした僕が、どのようにして投稿を続け、何を得たのかについてお話しします。

お話しする内容：
• どんな内容の記事を書いたのか（例：PHPのTipsなど）
• 毎日投稿して感じたメリット（知識の定着、反応がもらえる楽しさなど）
• デメリットや大変だったこと（ネタ切れ、モチベ維持など）
• 投稿を通して得られた成長
• やってみて感じた素直な感想

アウトプットって実際どうなの？毎日投稿ってどうやるの？といった疑問に、僕なりの答えを届けられたらと思います。
「自分も何か書いてみようかな」と思ってもらえるきっかけになれば嬉しいです！

私は数年前からPHPカンファレンスに参加しはじめ、当日スタッフや実行委員を経験し、毎年のPHPカンファレンスが楽しみです！
先日登壇したPHPerKaigiも最高でした！
この二件以外のカンファレンスには行けてないですが、PHPカンファレンスは各地で開催されています。
ぜひ皆さんに魅力を伝えたいです！そして願わくば一緒にスタッフや登壇をしましょう！
という布教活動です。

最近、AIを使ったコーディングについての話題を耳にすることが多いのではないでしょうか。
すぐに頭に浮かんだものだけでもCursor, Github Copilot, Devin, Clineと数が多く、他に様々なツールが出てきています。
モデルも、gpt4.1, claude3.7, gemini2.5など続々と出てきています。

このトークでは、私のチームでAIを使ったコーディングをどのように行っているのか。
そこに至るまでに何を試したのかをお話します。
また、私自身が不慣れなCakePHPを触る際に助けられた点にも触れます。

普段からAIを活用している方には少し物足りない内容かもしれません。
これから使ってみたい、実際どうなのか聞きたいといった方へ向けたトークとなります。

CakePHPで構築された社内向けシステムのMySQLを5.6から8.4へアップグレードしました。
その旅路は非常に困難で苦難の連続でした。

このトークではMySQLのバージョンによる仕様的な話は多くは語りません。
代わりに、どういった困難が起こり、どう乗り越えていったのかをお話します。

社内向けとはいえ、基本的にはデータベースを止めることができない中でどう検証し、どう方針を定めていったのかをご紹介します。

Hypervel is a Laravel-style PHP framework with native coroutine support for ultra-high performance. It ports many core packages from Laravel while maintaining familiar usage patterns, making it instantly accessible to Laravel developers.

This framework combines the elegant and expressive development experience of Laravel with the powerful performance benefits of coroutine-based programming. If you're a Laravel developer, you'll feel right at home with this framework, requiring minimal learning curve.

In this talk, I will introduce the key features of Hypervel, demonstrate its practical applications, and explain how it significantly outperforms Laravel Octane in high-concurrency scenarios.

Note: I will provide AI-powered realtime translation in this talk.
注: この講演ではAIを活用したリアルタイム翻訳を提供します。

PHP 8.4「プロパティフック」からオブジェクト指向設計を紐解きます。

プロパティフックとは、プロパティの読み書きに任意の処理を挟み込む機能です。従来の退屈なgetter/setterメソッドを使うことなく、より自然かつ柔軟な記述でプロパティの読み書きを実装できます。初めて使う際の学習コストも低く、手軽に導入できる点も魅力です。

一方、少し複雑な使い方や他の機能と組み合わせた使い方をしようとすると、型に関する制限や思わぬ仕様の違いに戸惑うことがあります。コンストラクタプロモーションとsetフックでの型の違い、readonlyとの併用不可、継承時の制限、これらは経験者でも混乱を招きがちです。

こうした仕様の背後には、オブジェクト指向設計の基本原則のひとつである「リスコフの置換原則（LSP）」が存在します。LSPは一見すると開発を窮屈にする制約のように感じるかもしれません。しかし、実はその制約が、アプリケーションの一貫性や信頼性を守るための重要な役割を果たしています。

本トークでは、プロパティフックの構文と振る舞いを整理しながら、なぜそのような制約が必要なのかを丁寧に紐解いていきます。また、LSPの考え方はオブジェクト指向の設計にとどまらず、より広い領域でも応用可能な「設計上のものの見方」であることにも触れていきます。

PHPの最新機能をきっかけに、日々の開発でも見落とされがちな設計原則の価値を改めて見直しましょう。

皆さん、「Laravelインターフェースの恩恵」を受けた！と感じたご経験はありますでしょうか？

自分はエンジニア歴3年で入社当初から、先輩エンジニアの方々から「インターフェースのありがたみ、いつかわかる日が来るよ！」「3年後かな〜5年後かな〜そのタイミングが来る時がある！」と教育して頂いてきました！

まだまだ自分自身、本当の意味での「恩恵」を感じられたか。と言うとまだまだですが
今回、3年程Laravel開発を経験した自分が感じた、「インターフェースのありがたみ」をご紹介出来たらと思います！

新人エンジニアの教育をされる方、またこれからエンジニアとして技術と向き合われる方皆様に少しでも有益なセッションになれれば幸いです！