MySQL や PostgreSQL は非常に安定した信頼できるプロダクトです。これまでの数々の実績を見てもそれは確実でしょう。

しかし、 IT 業界の規模が急速に拡大し、クラウドサービスが席巻している今、「1インスタンス1DB」を前提として設計されたそれらプロダクトには性能限界が来ています。つまり スケーラビリティの問題 です。
その問題を解決しようとしているのが Google Spanner や PingCAP TiDB などの NewSQL と呼ばれる新時代のリレーショナルデータベースです。
今回はその中でも TiDB に焦点を当てて、 MySQL や Spanner と比べたメリット/デメリットを実際に使って検証します。

対象者

• MySQL でスケーリング大変だ、と思っている方
• NewSQL(TiDB) の実力がまだわからない方

「なんで PHP をメインで書いているのに、 JavaScript(TypeScript) も一緒に書かないといけないんですか！ React ってなんですか！今は Svelte が良いって聞いたけどじゃあどれ使えばいいんですか！」

という問題を解決するかもしれないのが Laravel Livewire です。これを使えば、 PHP でフロントエンドのロジックを記述することが可能です。

今回は、 LaraconUS 2023 で発表された Livewire v3 と関連パッケージを使って、(ほとんど) PHP だけでフロントエンドロジックも実装してしまう技術を紹介します。

対象者

• JavaScript(TypeScript) しんどい方
• 「全部 PHP がいい！」という方

概要

データベースから結果セットを取得するデザインパターンとして、
Active Record パターンと Repository パターン（によって抽象化された Data Mappter パターン）がよく知られています。
これらのパターンは一体どういうもので、どのようなトレードオフによって選定されうるのかを解説します。

対象者

• ソフトウェアの設計に興味があるひと
• Active Record, Repository パターンを聞いたことがない、または聞いたことがあるだけなひと

もうちょっと詳しく

実質的には、PofEAA に記述されているパターンを PHP で再翻訳することになります。
PofEAA はあるパターンの説明に、別のパターンを使用することが多々あるため、その「らへん」についても紹介します。

エンジニアとしての道を歩む中で、ときおり「私はつよつよエンジニアと言えるのだろうか？」という疑念が私たちを襲います。
初心者の段階を脱し、中堅エンジニアとしても充分な経験を積むと、周囲からの期待も高まり、自身がそれに応えられるのかという不安が生まれることもあります。
自分に自信をもてないまま周囲から「あの人は強い」と言われるのは、少し毛恥ずかしいことですよね。
心の中では「PHPなんて生ぬるい言語を使っていてもつよつよエンジニアと言えるのか？」と不安がよぎることもあるでしょう。

このセッションでは、エンジニアとしてのキャリアのなかで、どのような経験や学びが自身の成長に繋がり、どうすれば自身の強さを発見できるのかを考察します
エンジニアとしての道を歩む皆さんが、自身の強みを最大限に引き出し、自己評価に自信を持ち、いつか「つよつよエンジニア」と自称できるようになる手助けをします。

概要

私たちが働く IT の業界は変化が激しく、既存のスキルが数年ですぐに陳腐化してしまいます。
変化のなかで生産性の高いエンジニアであり続けるためには新たな事柄を戦略的に学んでいくことが重要です。
本セッションでは戦略的な学習習慣を身につけること「学び方の学び方」についてブレイクダウンして考察していきます。

トーク内容

• 学ぶ人と教わる人
  • 未開の地を開拓するには自ら学ぶしかない
  • 自ら学ぶ人は常に教わるだけの人の先を行く
• 何を学ぶべきか？
  • あなたの欲は模倣である
  • 真に欲しているもののために学ぼう
• どのように学ぶか
  • 学習最適化組織を作る
  • ギバーとテイカーの組織的学習論

想定視聴者

• エンジニアとして成長し続けるヒントを見つけたい人
• メンバーが自ら学ぶ組織を作りたい人

PHPerのみなさん、皆さんの関わっているサービスはどこにデプロイしていますか？

AWS / GCPをはじめとする様々なクラウドサービス、レンタルサーバや専用サーバなどいろいろな環境を利用されているとおもいますが、PHPを利用したサービスで、「Azureを使っているよ！」って話はあまり多く公開されていないように思います。

では、PHPのプロダクトをAzure上で提供するのは困難なのかというと、全然そんなことはなくPaaS系のサービスを利用することで、運用コストをあまりかけずに提供することが可能です。

このセッションでは、PHPのプロダクトをホストする場合に利用可能なサービス・周辺サービスなどを、PaaS系のサービスを中心にご紹介するとともに、実際の運用でCI / CDなどをどのように構築しているかなどもあわせてご紹介します。

みなさん、Github Actions活用していますか？

昨今では、Github Actionsを使って自動テストや自動デプロイなどを実行している方はとても多いと思います。workflowを作成時に利用するActionは、Githubや各種ベンダーさん、OSSなどで様々な有用なものがたくさん公開されています。しかし、必要なActionがない場合、runアクションにコマンドを書いたり、シェルスクリプトを用意したりしてカオスになっていませんか？

このセッションでは、Github Actionsで動作する、独自アクションの作成方法や、既存のActionをカスタマイズする方法などをご紹介します。

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

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

その後、書籍「CPUの創りかた」で紹介されている4ビットCPU TD4を実装したり、Z80のハードウェアエミュレータを開発したりしています。

このトークでは私がこの数年で触れてきた4形態のCPUについて解説し、CPUの楽しさをみなさんにお伝えします。

どれも"CPU"ですが、それぞれ開発時に見える世界が全く異なっています。
このトークを通してみなさんがCPUの設計や動作に興味を持ち、いっしょにCPUについて語れることを楽しみにしています！

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

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

主なトピック:
・CPUを作るために必要なもの
・ソフトウェアエミュレータとハードウェアエミュレータの違い
・Raspberry PiでCPUを作る方法

CPUを作ってみたい方はもちろん、コンピュータの仕組みを理解したい方や、プログラムが実行された時にコンピュータの中で何が起きているのかを知りたい方などにもお楽しみ頂けると思います。

「コンピュータは0と1しか処理できない」とよく言われています。
ビット演算があったり、浮動小数点演算があったり、文字コードが16進数だったりと、PHPerのみなさんもなんとなく実感としてはあると思いますが、なぜ「0と1しか処理できない」のでしょうか。

このトークではアナログの世界・電気回路でデジタルの世界・コンピュータ処理がどの様に表現されるのか、私たちがC言語やPHPで書いたプログラムの実行結果がディスプレイやスピーカーで認識できるところまでがどの様にできているかをお話します。

ふだんの活動ではあまり気にすることのないコンピュータの基本的な仕組みの話になりますが、このトークを聞いたみなさんが今までより少し解像度の上がった目でコンピュータを楽しめることを願っています。

世の中には様々な技術が存在します。

皆さんはその中からどのような基準で技術を選定していますか？
そしてどのような環境で開発をしていますか？

本セッションでは、テックリードとして行ってきた、技術選定や開発環境の整備等について、どのような取り組みをしてきたのか、成功談や失敗談と共に解説いたします。
本セッションを通じて
「どういう基準で技術選定をすればいいかわからない」
「コード品質をどのように保てばいいかわからない」
「テックリードって何をしたらいいかわからない」
といった方が参考にできるような時間を提供いたします。

皆さんは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) 資格を取得しました。そして、大規模プロジェクトにおいて、先輩のスクラムマスターがスクラムを導入していく様子と、その変遷に携わった経験を通して得た知見を、このセッションで皆さんと共有したいと考えています。

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

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

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

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

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

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

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

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

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

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

組織、変えていますか！

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

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

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