トーク

前回のPHPカンファレンス福岡2019で「JAMstackアーキテクチャを用いたモダンWebサイト開発」というタイトルでFusicのテックブログにJAMStackアーキテクチャを取り入れた話をさせてもらいました。
あれから約4年ほど経ち、静的サイトジェネレーターをGridsomeからAstroへ移行しました。

Astroは最近注目されているWebフレームワークの一つで、「Astro Islands」というWebアーキテクチャパターンにより、不要なJavaScriot読み込みを無くし、高速なWebサイトを実現できます。

移行によって得られた最適化効果により、ページの表示速度が向上し、Lighthouseのスコアが満点のページ、または満点に近いスコアのページを生成できるようになりました。
体感でのページ表示速度もさらに速くなったと感じます。

本セッションでは、移行の経緯、Astroを選択した理由、移行時の苦労、今後の課題についてお話します。

私たちの運営するサービスは、コア機能部分が未だにレガシーコードとなっており、リファクタリングが必要な状況になっていました。
しかし、影響範囲が大きくテストもないので中々触りたくない、サービスの成長（機能追加）のための開発と両立できない、自分の担当プロジェクト以外は分からない、等など一筋縄では行かない問題もありました。

そこで私たちは、月に一度、大規模にリファクタリングが可能な日（リファクタリングデー）を設けました。
リファクタリングデーでは通常の開発を１日止めて、コア機能も含めた影響範囲の大きい箇所のリファクタリングを行い、全ての機能をQAしてリリースします。

このトークでは、リファクタリングデーを行うために何をしているのか、また、実際に１年ほど行って感じたメリットや、課題などについて説明します。

話すこと

• 大規模にリファクタリングを行うための開発フロー（スケジュール）
• あまりコツは必要無いという話し

話さないこと

• リファクタリング手法・設計の話し
• 自動化などの仕組みの話し

備考

https://developers.prtimes.jp/2021/12/13/introducing-refactoring-day/

Github ActionsでDockerイメージをビルドしてデプロイしています。
当初、Dockerイメージのビルド時間がとても長く、デプロイまでに時間がかかってしまっていました。

そこで、Dockerfileを見直しレイヤーキャッシュを意識するようにしたところ、コンテナビルドの時間を短縮することができました。

Dockerイメージビルドにおいて、レイヤーキャッシュを活用することはビルド時間を短縮し、開発効率を向上させることにつながります。

本トークでは、

• Dockerとは
• Dockerイメージとレイヤーキャッシュ
• Github Actionsにおけるキャッシュの利用
• Github Actionsでのコンテナイメージのビルド

という内容に触れつつ、Dockerのレイヤーキャッシュを利用したイメージビルドの方法やビルド時間を短縮するための方法について説明させていただこうと思います。

なんと世の中にまだこの言葉が無いので、トークで伝えたい！

• Google 検索
• Twitter 検索
  • 私が発した言葉のログしかありません

※PHP とは関係ありませんが、開発チームとしての考え方が今日から変わるかも！？

フルリモートで仕事をするようになりはや3年。どうしても対面での働き方とは変わってきた部分がいくつもありました。
このトークでは私が今の会社で日々意識していることや実践していることを共有していきます。主にテキストコミュニケーションやオンライン上の仕草について紹介します。

リモートワークでの働き方に不安を持っている方や検討している方にぜひ聞いてもらえたら嬉しいです。

ソフトウェア開発において、私が重要だと考えるアプローチは「可能性を狭める」というものです。例えば、型宣言を指定して値が取り得る範囲を絞り込みます。これにより、コードを読む際に考慮しないといけない範囲を限定できます。これは認知負荷を下げることに繋がり、引いては読みやすいコード、変更しやすいコードにできます。さらに、宣言する型を独自に定義した型にすることでその範囲をより狭くできます。こうした型による制約は、静的解析ツールや PHP ランタイムによって機械的にチェックされると言うのも大きな利点です。

一方、こうした制約を設けずに多機能なクラスを作成することで、可読性やメンテナンス性が低下し、問題が生じると言う経験をした人もいるのではないでしょうか。

このアプローチは、型システムだけでなく、クラスやモジュール設計、ソフトウェアアーキテクチャ、デバッグやパフォーマンスチューニング、自動テストなど、開発の多くの側面に適用可能です。

本セッションでは、特にまだ開発経験が浅い方や開発タスク自体はこなせるようになってきた方に向けて、今後さらに現場で活躍していけるように基礎となる考え方として知っていただきたい内容をお話しできればと思います。

伝えたいんです。オフラインのカンファレンスの素晴らしさを。

カンファレンスに行ったことがない人、初めて参加した人などからはこういった声をよく耳にします。

• 「カンファレンスってすごい人がいっぱい行くところでしょ？」
• 「私は全然技術力ないし、普段勉強してないから行っても何もわからないし…」
• 「興味はあるけど知り合いが居ないから1人で行ってもなぁ…」
• 「自分はコミュ力無いから話しかけるのとか無理だ…」

そんなとき、私はいつも
「違うんです…！すごい人ばかりが来ているわけじゃないんです…！」
「わからなくても大丈夫！1つ単語を覚えて帰ってきたらそれでいい」
「カンファレンスでの会話にコミュ力は必要ないのになぁ…」
と、思いながらカンファレンスの良さや、初めて参加する人へのアドバイスをたくさんの人に伝えてきました。

このトークはそんな方に向けて、学生時代に初めてカンファレンスに参加したことがきっかけで自分の人生が変わった参加歴6年のカンファレンス大好きな私が、様々なカンファレンスに参加し続けたことで得た「カンファレンス参加者として楽しむためのコツ」をたっぷり詰め込んだトークとなっています。ぜひ聞きに来てください！
また、カンファレンスジャンキーの方も、我々の仲間を増やすためにどういうふうに良さを伝えたらいいんだろう…と悩んでいることでしょう。カンファレンスへの誘い文句の参考になるトークをするのでご安心ください。

※このトークはPHPerKaigi 2023のアンカンファレンスで「カンファレンスで友達を作るコツ」としてLTした内容をブラッシュアップしたものです。

話すこと

• カンファレンスに参加するメリット
• 当日聞くセッションの選び方
• セッションを聞いたスピーカーに話しかけよう！緊張しなくて大丈夫、スピーカーは話しかけられたくてたまらないんだ。
• 参加者同士で話題にしやすいカンファレンスで話しかけるときの鉄板フレーズ集
• それでも話しかけられない？そんなときは〇〇に話しかけよう
• カンファレンスで出会った人との繋がり方、その後のコミュニケーション方法について

PHP 処理系内でメモリのどこに何があるか、を意識してプログラミングをしたことがありますか？

2020 年頃から、PHP で PHP のプロファイラを作っています。
これは プロセス外から FFI を通じてシステムコールを呼び、対象プロセスのメモリ内容へアクセスし、実行中の処理系内部の C 言語構造体のデータを直接読み取るという仕組みで動作します。
https://github.com/reliforp/reli-prof

さて、このスクリプトを動作させるには、処理系内でどこにどんなデータがどのような形であるか、を詳細に把握する必要があります。そしてその構造知識をコード内へ転写していくことでツールの機能を追加していけるのですが、この過程で私自身の中にもちょっとした変化が現れてきます。ふつうの PHP スクリプトを書きながらでも、プロセス内でメモリがどう使われどのような処理でアクセスされるかを、なんとなく把握できるようになっていくのです。

このトークではツール作成の過程で得られた処理系内のメモリレイアウトについての知識を幾つか紹介し、聴講者の皆さんも PHP スクリプトを書きながら裏側のメモリ構造がうっすら透けて見えるという状態になることを目指します。

対象聴講者はたとえば以下のような項目が気になる人です。

• 変数や値がどうメモリ内に格納されているか
• interned string とは
• 配列がどうメモリ内に格納されているか
• オブジェクトがどうメモリ内に格納されているか
• 「クラス」はメモリ上でどういう構造のものなのか
• 宣言された引数と動的な引数の違い
• 宣言されたプロパティと動的プロパティの違い
• opcache でキャッシュされた内容のメモリ上での表現
• apcu でのキャッシュのメモリ上での表現

オンプレだったPHPアプリケーションをコンテナ化してWEBとバッチをクラウド化（AWS）しました。
今まで全くインフラの仕事はしておらず「インフラをしてないからわからないこと」が怖かったり、課題にぶつかった時に何もわからない自分を変えたい！！と思っていました。
そして機会があったため手をあげてSREと協力しながら実現させました！

今回私がまるっとインフラ周りを経験したので「普段アプリケーションをさわってるけど、インフラもやっていきたいんだよなあ・・・」と思っている人がはじめの一歩を踏めるような「やわらかい説明」でインフラの話をします！

■ 話すこと
クラウド化で発生する作業ってなんだっけ？（ECS / Docker / デプロイ / ... ）
実際のタスクを進める上での悩み・詰まりポイント
クラウド化後に起こった想定外だったこと

■ 想定する聴衆
「インフラ興味あるけどなんもわからん」と思っている1年前のアプリエンジニアの私向けに作ります
総合して初学者向けです

テスト初心者の皆さん、このような悩みを抱えていませんか？
・テストメソッドとテストデータが混在していて読みづらい
・テストの出力結果が見づらい
・テストの実行範囲を明確にしたい

このトークでは、PHPUnitのアノテーション機能を使って初心者でも可読性と保守性の高いテストコードを書ける方法を紹介します。
・@dataproviderを使ってテストケースをまとめ、再利用する
・@testdox × @dataproviderでテストメソッド名をよりわかりやすく表現する
・@groupを使ってテストをグループ化する

これらの機能は明日からすぐに使える簡単なものです。
アノテーションを活用し、見やすいテストコードでスムーズにテストを実行しましょう！

みなさん、テストを書く際にどうやってテストデータを用意していますか？
PHPのフレームワークであるLaravelではfakerphp/fakerを使用し、簡単にランダムなテストデータを生成することができます。また、メールアドレスや人名、絵文字などを作成するように指定することもでき、大変便利なライブラリです。

しかし、何でもかんでもランダムにテストデータを生成していると、テスト対象のロジックをテストの中で実行し、アサーションをするといったことを意図せずしてしまうことがあります。
また、ランダムなテストデータを使っているからといって境界値テストを怠ったり、Property based testingのようなテスト観点が抜け落ちたりすることがあります。

本トークではFaker（ランダムでテストデータを生成するツール）を使用しない方がいいテストや、境界値テスト、Property based testingについてお話しします。

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

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

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

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

コンピュータは現実世界に存在するモノです。コンピュータの実態は電気回路ですが現実世界に存在する以上はアナログの世界に存在しています。
一方、コンピュータは計算機であり、計算する対象はデジタルな離散値です。
過去に、アナログ計算機や、電気を使わない機械式のデジタル計算機も存在しましたが、現在主流なのは電気回路からなるコンピュータです。
コンピュータが「0と1しか処理出来ない」のは、電気回路でデジタルな計算を効率良くするための工夫なのです。

このトークでは「電気回路でCPUがどの様に表現されるか」から、私たちがディスプレイやスピーカーでコンピュータの動作を認識できるところまでがどの様にできているかを以下の様なトピックを中心にお話します。

・電気回路上での0と1
・コンピュータの構成要素 - CPU, I/O, メモリ
・本当に演算だけをしている「中央演算装置」ことCPU
・いろいろなメモリ: 近い or 遠い, 安い or 高い, 速い or 遅い, 小さい or 大きい
・キーボードもディスプレイもBluetoothも…多岐にわたるI/O
・デバイスを結ぶ通信路: バス

初心者の方から上級者の方までお楽しみ頂けるトークになると思いますのでぜひ聞きに来て下さい！
このトークを通して、コンピュータ好きの方が増えること、そんなみなさんで楽しいコンピュータ話をすることを楽しみにしています！

プロジェクトでスクラムに倣った開発をしてみて、私はスクラムマスターとしての役割で半年間運用しています。
チームメンバーはアジャイル開発について言葉は知っていたし、「スプリント」でのタスクの回し方、「レトロスペクティブ（ふりかえり）」などはスクラムっぽく回した経験はありました。それにさらに「リファインメント」「スプリントレビュー」などをやってみました。しかしルール通りにできないところもあり、悩みました。そして自分達のPJにFitするにはどうしたらいいだろう？を考えて工夫して取り組みました。その話をします。

■ スクラムとは（ゆる〜く）
■ プロジェクトで大事にした「アジャイル開発」の要素
■ 定義通りにやれなかったところ、Fitさせるために取り組んだこと
・きちんとしたプロダクトオーナーを依頼できない問題
・スプリント中にぽろぽろ出てくる「考慮不足」「新たなタスク」がでてくる問題
・タスクの依存関係のせいで暇な人がでてくる問題
■ アジャイル開発をキチンと採用してみて解決されたプロダクトの課題

■ 想定する聴衆
アジャイル開発を回している人
アジャイル開発を回してみたい人
アジャイルの概念はなんとなく知っている人

Twitterの変化が激しい今日この頃、ツイッタラーの皆さんはいかがお過ごしでしょうか？
私は普段から技術情報の収集などあらゆる面でTwitterにお世話になっており、ホームと言っても過言ではありません。
しかし、最近はエイプリルフールでもないのに突然アイコンを犬に変えるCEOの采配などに不安を感じています。

万が一の際の移住先を色々と調べた中で、技術者としても興味があるCloudflareのWildebeestに手を出すことにしました。

WildebeestはActivityPub＆Matodon互換サーバーであり、Cloudflare PagesとPages Functionsで稼働するフルスタックアプリです。
CloudflareアカウントとCloudflareを使用したDNS zoneが１つあれば、手持ちのドメインでセルフホストすることができます。

• データベースに D1
• オブジェクトキャッシュに Workers KV
• 認証に Zero Trust Access
• 非同期ジョブに Queues
• メディアに Images

と、Cloudflareが提唱するSupercloudの見本市とも言えましょう。

私も以前からエッジコンピューティングには注目してはいたものの、読込の多いWebサイトのようなシステムにしか向いていないのではないか？という偏見がありました。

MastodonのようなWebアプリがエッジでまともに動く？ 本当に？

本トークでは、Wildebeestの利用を通じて、最近ノリにノッているCloudflareのSupercloudを覗いていきます。

● 話したいこと

• Cloudflareの提唱するSupercloudという概念
• Wildebeestの構成とCloudflareのプロダクトについて
• Wildebeestを運用してみた感想
• パフォーマンス面

● 話さないこと

• PHP

【概要】
プロダクト開発・運用において、顧客要望への対応や新規顧客獲得が優先されることが多い中、技術的負債や陳腐化の解消が後回しにされがちです。本セッションでは、継続的かつ効果的に技術的負債と陳腐化の解消を実現するための戦略やルールを、自社プロダクトでの実例とともに紹介します。

【内容】
・プロダクト開発における機能追加・改善・ 技術的負債・陳腐化の解消のバランス
・技術的負債と陳腐化の解消に向けた取り組み
・意思決定者に対してROIや緊急性を効果的に伝える方法

【対象者】
・プロダクト開発・運用に携わる方々（エンジニア、プロダクトマネージャー、営業担当者など）

タイトルを見て驚かれた方もいるかもしれません。
そう、サポートの切れた 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について語れることを楽しみにしています！

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の楽しさをみなさんにお伝えします。

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

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

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

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

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

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