トーク

世の中に入門書や入門者向けの記事は溢れています。
上級者向けの書籍や記事も増えています。
入門書を終えた後、次のステップに進むために何を学ぼうか悩んでいるビギナーの方は多いのでは無いでしょうか？
PHPを使って業務で開発を行っていくうえで、次のステップとして学ぶと良いことをお話ししていきます。

◆対象者
・入門書をやり終えた程度のPHP初心者
・簡単なWEBアプリケーションが作れるようになったPHP初中級者

◆話すこと
・バグを生み出しづらい書き方
・コーディング規約
・チーム開発において読みやすい書き方
・コメントの入れ方
・セキュリティを意識した書き方
・エラーの見方

内製開発チームを立ち上げて半年程度のスタートアップに昨年ジョインし、7月からCTOをやっております。
14名の開発チームに成長、サービスの展開を加速させていく中で、組織作りや開発基盤の整備を含め、取り組んできたことをPHPer目線でお話しします。
CTOに限らず似たような立ち位置の企業にジョインしたエンジニアの参考になればと考えています。

◆対象者
・スタートアップエンジニア
・新規の開発チーム立ち上げをしている人

◆話すこと
・エンジニア組織作り
・採用、技術広報
・経営層、他部署の知識向上
・開発環境、ルール作り

「あーあれでしょ、なんか、なんか、ファイル呼び出し良い感じにしてくれるやつ！！」
かつての私のautoloadとの向き合い方はこのレベルでした。
（いや、なんならもっと解像度が低かったかもしれません・・・）
「Composerを「なんとなく使う」から「理解して使う」になる」という発表を別イベントですることになってから、Composerと向き合い、Composerときちんと向き合い彼らとの絆を得ました。
本セッションでは「autoloadってなんだっけ？」から入り、どのように動いているか、また、そもそもComposerを使っていない、namespace採用ができていない、...とかいう拡張が難しいアプリケーションサービスにautoload機能を導入する話も折り入れ話して行きます！

■ autoloading機能とは
■ どのように動くか、コードを見ていく
■ PSR記法について
■ 拡張が難しいアプリケーションでautoloadを導入した話

■ 想定する聴衆
Composerをなんとなく使ってる人
autoload機能あんまり意識して使ってない人

タイトルを見て驚かれた方もいるかもしれません。
そう、サポートの切れた Laravel 6 を利用しているプロジェクトがまだこの世にはあるんです。

最近は意識が変わってきていますが、継続的なシステム開発において、
目に見える機能改善とは異なり、バージョンアップやリファクタリングに時間を割かれる事例は稀です。

それでも、長い、長い、交渉の末に、バージョンアップの機会を手に入れることが出来ました。

このセッションでは、Laravel 6 で4年運用されてきたシステムを Laravel 10 に移行すると共に、
構造が古く、メンテナンス作業の足枷になっていたアーキテクチャの再考をしたプロジェクトについて、
実際に遭遇した問題と解決策を交えながら、知見の共有を行ないたいと考えています。

フルスクラッチで開発を行うプロジェクトとは異なる性質のプロジェクトにおける準備や勘所、そして覚悟をみなさまに共有できたらと思っています。

CPUが好きです。
私は中学生の頃にMSXというパソコンを入手し、MSXのCPUであるZ80のマシン語をプログラミング言語として体験していました。

時を経ること25年、2016年にPHPで書かれたゲームボーイエミュレータのコードを読んで衝撃を受けました。ゲームボーイのCPUはZ80をベースに開発されたものであり、ゲームボーイエミュレータのコードで実装されていたのはまさにそのZ80の命令だったのです。

その瞬間、それまで「よくわからないけどすごいプログラム」だと思っていたエミュレータのコードが、ハードウェア仕様をそのままソフトウェア的に表現したものであることが理解できました。

そしてその3年後、2019年に名著「CPUの創りかた」で紹介されている4ビットCPU TD4を実装し、そこでまた衝撃を受けました。そこに見たCPUは、プログラミング言語として見たCPU、エミュレータの対象として見たCPUのどちらとも違い、電気回路として命令の実行が表現されたものでした。

これで完全にCPUに心を奪われた私は、2022年から趣味プロジェクトとしてZ80のハードウェアエミュレータを開発しています。
これはZ80で動作しているコンピュータからZ80を取り外して、代わりに自作のZ80ハードウェアエミュレータを取り付けて動作させるというもので、Raspberry Pi に自作のハードウェアを接続した形になっています。

このトークでは私がこの数年で触れてきた4つのCPUのうち、特に電気回路として作ったCPUとRaspberry Piで作ったCPUの2つにフォーカスしてCPUの楽しさをみなさんにお伝えします。

・物理CPU Z80
・PHPで書かれたZ80ソフトウェアエミュレータ
・電気回路として作った4ビットCPU TD4
・Raspberry Piで作ったZ80ハードウェアエミュレータ

どれも"CPU"ですが、それぞれ開発時に見える世界が全く異なっています。
初心者の方でも楽しめる様にお話しするつもりですのでお気軽に聞きに来て頂ければと思います。
このトークを通してみなさんがCPUの設計や動作に興味を持ち、いっしょにCPUについて語れることを楽しみにしています！

現代のコンピュータはハードウェアから私たちプログラマが書くプログラムの動作までの間が多くのレイヤーに分けられて動作しています。
レイヤーは自分より下を抽象化し、下のレイヤーを詳しく理解しなくても多くの場合プログラマはプログラムを書けます。
一方、プログラムが期待した様に動作しない時には下のレイヤーの動作の理解が問題の解決の助けになることもあります。

このトークでは私たちが愛するPHPをスタート地点にして、コンピュータプログラムがどの様に動作するのかを解説します。

・PHPプログラムが実行される時にコンピュータ内部で起きていること
・2種類の"プログラム実行" - CPUかそれ以外か
・CPUによる"プログラム実行"
・インタープリタ - PHPやJavaとC言語の根本的な違い

コンピュータのレイヤー構造を理解するとプログラミングに役立つだけでなく、いままでは見えていなかったレイヤーのプログラミングを楽しめるようになります。
このトークを通じて、低レイヤーが好きになったり、いろいろなレイヤーで面白いことをしたりする方が増えることを期待しています！

私はこの数ヶ月、趣味プロジェクトとして1980年代に栄華を誇った名作CPUである"Z80"のハードウェアエミュレータを開発しています。
これはZ80で動作しているコンピュータからZ80を取り外して、代わりに自作のZ80ハードウェアエミュレータを取り付けて動作させるというもので、Raspberry Pi に自作のハードウェアを接続した形になっています。

このトークではZ80ハードウェアエミュレータの解説を軸に、CPUの作り方や、その楽しさをお伝えします。

主なトピック:
・Z80ハードウェアエミュレータの構成
・CPUを作るために必要なもの
・Raspberry PiでCPUを作る方法
・Z80ハードウェアエミュレータの課題とその解決方法

CPUを作ってみたい方はもちろん、コンピュータの仕組みを理解したい方や、プログラムが実行された時にコンピュータの中で何が起きているのかを知りたい方などにもお楽しみ頂けると思います。
このトークを通じて、CPUに興味を持ち、CPUについて語る仲間が増えることを期待しています！

エンジニアの生産性には、優秀な人とそうでない人との間に大きな差があると言われています。
その差はどこからくるのでしょうか？
今回は「学習」という側面にフォーカスしながら、生産性の高いエンジニアであり続けるための戦略について考えてみます。

エンジニアの生産性の差は、ひとつには教わるだけの人と自ら学ぶ人との学習姿勢の差が反映されたものです。
自ら学ぶ人は常に教わるだけの人の先を行きます。それどころか「学び方を学ぶ人」はさらにさらに先を行くことになるのです。

技術・環境・ツールの変化が激しく既存のスキルがすぐに陳腐化してしまう現代において、「学び方の学び方」こそが重要なスキルになります。

このトークでは、エンジニアに欠かせない学び方の学び方と、自ら学ぶ集団の作り方について共有し、みなさんと共に考えていければと思います。

人生は後悔の連続です。
それはシステム開発の現場においても同様と言えます。

Minimum Viable Product だ！必要最低限の機能に絞って実装しよう！
データベースは正規化して、nullable は排除、データベースで整合性を担保しよう！
CI/CD 環境を整えて不安の無いデプロイを実現しよう！

全て3年前のプロジェクトメンバーが聞いたら納得する内容です。
実際に私も納得して開発していました。

しかし、システム開発において想定外の事態というものは必ず存在します。
1つのシステムを横展開するという企画から始まったシステムも、
今や50を超える類似システムが存在します。

「類似」システム……。
そう、何一つとして同一のものはないのです。

度重なる仕様変更。
崩れる正規化。
壊れるブランチ戦略。

そんな、横展開の闇に揉まれながら、血を流しながら、システムを改善していく、

「システム開発現場のリアル」

についてお話したいと思います。

データベースのレコードがどのような経緯で現在の状態になったのか分からず、困ったことはありませんか？
Event Sourcingは、アプリケーションの状態変更をイベントとして記録し、それを用いてアプリケーションの状態を再構築するアーキテクチャパターンです。このトークでは、LaravelでEvent Sourcingを実装する方法について、具体的な手順と実践的なパターンを紹介します。

• Event Sourcingとは
• Event Sourdingのユースケース
• Event SourcingをLaravelアプリケーションで実装
  • Projector
  • Reactor
  • Aggregate
  • Serializer
• ドメインごとのイベントストア
• テストの書き方

みなさん、 Web 、してますか？ Web アプリケーションの一つに 「 3D リアルタイムレンダリング」 があります。 WebGL と呼ばれる技術を用いて、ネイティブアプリのように滑らかに動作するゲームやショーケースなどを作ることが出来ます。
その中でも今話題沸騰なのが WebGPU という新しい規格です！これは Vulkan や Metal のように GPU を直接呼び出す新しい技術で、今まで WebGL1, 2 で作られてきたものよりも効率的に 3D レンダリングを行うことが出来るようになります。
これは現在 Google Chrome の最新版に 4 月中にリリースされる予定となっていて、もうエンドユーザーに届けられる段階にあります。

その WebGPU を一足先に、一年前から対応していた 3D リアルタイムレンダリングライブラリが Babylon.js です。これは皆さんおなじみ（？） TypeScript で作られているフレームワークで、非常に簡単な API で豪華なアニメーションや VR/AR 表現を行うことが出来る素晴らしいプロダクトです。

しかし、悲しいことに Babylon.js の採用事例はまだ国内外ともに少なく、もったいない状態になっています。そこで、普段 PHPer である皆さんにも是非触って欲しい。ゲーム作ってみて欲しいということで、今回紹介させて頂きたいと思います！

ターゲットユーザー

• 新しいものが好きな全てのエンジニアの皆さん
• TypeScript が好きな皆さん
• ゲーム作ってみたい皆さん

考古学（こうこがく、英語: archeology）は、「人類」が残した「遺跡」から出土した「遺構」などの「物質文化」の研究を通し、「人類の活動」とその変化を研究する学問である。（Wikipedia）
つまりアーキテクチャ考古学とは、「先人」が残した「コード」から出土した「遺産・負債」などの「アーキテクチャ」の研究を通し、「プロダクト」とその変化を研究する学問である。（Akito.Tsukahara）
みなさん、こんにちはアーキテクチャ考古学者のAkito.Tsukaharaです。
この登壇では、新しく入社してくれたメンバー達へのオンボーディングをするために、考古学した（弊社のプロダクトのアーキテクチャを研究、文言化して、社内で勉強会）取り組みについて発表させていただきます！
考古学することには、「システムの理解とドメイン知識の向上」や「技術的負債の認知」をオンボーディングで伝えることで
新メンバーが少しでも楽に現場の開発に慣れてもらう意図があります。
この発表をご覧いただくことで以下の情報をお届けできます。
・考古学のやり方
・アーキテクチャに関する知識・ノウハウ
　・レイヤードアーキテクチャ
　・テスト設計　etc...
・オンボーディング資料の作り方
・社内勉強会でチームの巻き込み
など

我々アプリケーションエンジニアにとってデータは非常に重要なものです。
皆さんもRDBのデータ、ログデータ、分析データといった色々な種類ものを扱うことが多いのではないでしょうか？

しかし、これらのデータはエンジニアだけのものではなく、マーケター、事業責任者といったプロダクトに関わる全員が関わるべきものではないでしょうか？
そのためには、SQLの習得といったスキルの問題や、業務サービスへのアクセス権限といったガバナンスの問題もあり、なかなか難しい課題なのではないでしょうか？

そこで、我々の開発チームでは、開発だけでなくプロダクト全てのサイクルに関わる"Fullcycle Developers"という標語を抱えています。
その一環で、我々が作ったプロダクトの成果をデータ含めてフィードバックループを作るようにしています。

その結果、BIツールを用いて、SQLを出来る限り書かずともチームの皆がデータを可視化・確認できるようになり、開発に関する議論も職種問わず活発化しました。

そこで今回のトークでは、我々のチームが、どのようにデータの民主化を進めていったのか、データの民主化によってどのような変化があったかをお伝えします。

具体的なBIツールなどの使い方などに関しては話さない予定です。

アプリケーションを開発するなかで設計手法が必要と感じたら、DDD（ドメイン駆動設計）が選択肢の一つです。

最初からアーキテクチャを導入するわけではなく、約10年成長してきたLaravel的なEloquentを活用したMVCで作られたアプリケーションにアーキテクチャを導入する際、悩みや数々の試行錯誤がありました。

私たちの経験を元に、オニオンアーキテクチャをベースに、既存コードの対処法やネームスペース、クラス分割のコード例と背景を紹介します。

想定対象

• 既存プロダクトにDDDを導入したい方
• Laravelにオニオン（レイヤード、クリーン）アーキテクチャを取り入れて見たい方

話すこと

• 既存コード（主にEloquentとUtilクラス）との付き合い方
• ネームスペースの切り方と背景
• クラスの分割と背景
• DIの方針と背景

話さない内容

• DDDを使う理由
• モデリングに関すること
• ドメインロジックの定義

ウェブサイトのコンテンツ管理とテンプレーティングはWWW初期から長らく課題とされてきました。

コンテンツ管理システム(CMS)というアイデアの原型が生まれたのは25年ほど前ですが、現在でも世界のウェブサイトの多くはWordPressに代表されるCMSで運営されています。
一方で、コンテンツ管理とテンプレーティングという課題に対する別のアプローチとして、静的サイトジェネレータ(SSG)という概念も発生し、今日でも発展を続けています。

CMSとSSGは二者択一のものとして解釈されがちですが、近年ではHeadless CMSのような折衷案も登場しており、周辺のスタックまで含めると選択肢は無数に存在すると言えるでしょう。
これらの選択肢を個別に検討するときりがありませんが、検討のための手がかりはないのでしょうか。

スピーカーはその手がかりが「歴史」にあると考えています。
ある技術やソフトウェアが開発されるには、それまでの出来事からニーズが発生するためであり、そのニーズを読み解くことで強みを見抜くことができるでしょう。

LAMPからJAMStack含め最新の動向まで、WWWの歴史やエンジニアリングの歴史とともに俯瞰していきましょう。

先日、4月19日に福岡発のオープンソース、baserCMSの最新バージョンがリリースされました。
世の中において、PHPにおけるフレームワークのニーズは、Laravelがうなぎ登りですが、baserCMSは、オープンソースとして外部のコードが受け入れやすいよう、規約重視であるCakePHPを採用し、最新バージョンもCakePHPで開発されています。

最新バージョンであるbaserCMS５の開発では、レガシーコードからの脱却を目指し、これまでの12年間の開発で熟成した「秘伝のタレ」的なコードを全て見直し、モダンな開発プラットフォームとして成長しています。

実は2017年より、ゆっくりとその開発が始まりましたが、その過程の中で、目指すCakePHPのバージョン対象が３から４へと変化し、そして、先日のbaserCMS５のリリース前に、ついにCakePHP５のベータ版が勧告されてしまいました。

このセッションでは、開発中のエピソードや移行のポイント、また、DIやサービスなどの概念を踏まえ、土台となるフレームワークがどのように変化しようと心が折れないアーキテクチャーとは何かについてお話できればと思います。

B+木をご存知でしょうか？RDBMSのインデックス作成に採用されているデータ構造で、ディスクの効率的な利用や、検索を行いやすいなどの特徴があります。しかし、耳学問で聞いてもイマイチ特徴がピンと来ないのです。

本トークでは、PHPでB+木のデータ構造を実装して、RDBMSでB+木が採用される理由、インデックスの構造的な仕組み、何故検索が速くなるのか？などなど、データベースの仕組みの根幹を覗いてみましょう。

本トークで話す内容

• B+木の特徴
• なぜ、データベースはB+木を採用しているのか
• インデックスとは何か

2023年11月23日に PHP 8.3 がリリースされます。本トークでは、追加が確定している新機能を紹介すると共に、その機能がどんな議論を経て追加されたのか、この先の展望も含めてわかりやすく解説します。

また、要望はされたものの却下された機能の話や、現在議論中の機能についても紹介します。

本トークで話す内容

• 現時点で追加が確定している機能
• これから追加される見込みの機能
• 要望はあるものの追加されなかった機能

Notionはとても優れたドキュメンテーションサービスであり、ある程度使い方を覚えてしまえばこれまで様々なWebサービスを組み合わせて仕事していたものが使い方次第でNotionだけでそれらが行えて便利なことから、自身が所属する会社においても導入後はエンジニアに限らず様々な職種の方々が利用しています。

自身が所属する事業部内で私は複数のサービスを運用するチームにも所属しており、そこで最も利用しているNotionの機能はデータベース機能です。Notionのデータベース機能とは単なるページの集合体ではなく、フィルター機能や各種ビュー機能などが備わっていることから、複数のサービスの仕様や運用マニュアルなど膨大な量のドキュメントを分類して管理するのにとても便利な機能であり、すでにサービスの運用を行う上では欠かせないものとなっています。

しかしそのようなデータベースをここ2〜3年管理する中、ドキュメントやデータベースが日々増加してきたことで以下のような課題や要望が発生してきました。

• 問い合わせ対応をする上で運用マニュアルを管理するデータベースから知りたい情報がうまく見つけられない場合がある
• 仕様や運用マニュアルなどコンテキストごとに複数のデータベースを作成しているが、それらの情報が連携できておらず欲しい情報にうまくたどり着けない
• 普段Slackで運用メンバー同士がコミュニケーションをとっているのでそこからNotionの情報にシームレスにアクセスしたい
• サービスの仕様などサービスにとって重要なドキュメントはレビューした上で更新したい

このような課題や要望を解決するために運用しているルールや利用しているツールなど、自身が所属する組織においてどのようにNotionを活用してサービスを効率的に運用しているかについての知見を共有したいと思っています。

近年、PHPプロジェクトの品質を高めるためのツールとしてPHPStanのような静的解析ツールが導入されるケースが増えています。

しかしながら、PHPStanをただ単に導入しただけではバグを完全に潰すには足りません。
PHPStanに新たなルールを加え、更に厳しくするためのPluginがphpstan-strict-rulesです。

PHPには厳密性に欠ける関数が散在します。
例えば、 in_array に第三引数を渡さないと厳密性が損われるので警告を出してくれるといったものです。

phpstan-strict-rulesを普及すれば、誰もが安心して開発できる環境が整うと信じています。

対象

• 既存のPHPStan level maxでは満足できない身体になってしまった人
• PHPStanでは捕捉しきれないバグに遭遇したことのある人
• 型に厳しい別言語から来た人