トーク

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

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

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

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

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

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

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

本トークでは、

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

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

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

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

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

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

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

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年前のアプリエンジニアの私向けに作ります
総合して初学者向けです

みなさん、テストを書く際にどうやってテストデータを用意していますか？
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言語の根本的な違い

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

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

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

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

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

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

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

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

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

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

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

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

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

PHPカンファレンス福岡2023へのプロポーザルを提出するにあたり、
社内のメンバーに何か聞きたいことがあるかヒアリングしました。

結果「打ち合わせがすごい」「打ち合わせのコツが知りたい」という声をもらったので
自分の打ち合わせに関する技術を言語化できればと思います。

打ち合わせは非常にコストの高い業務です。
参加メンバーも多く、メンバーの時給を合算すると意外に多額の予算を消費してしまっています。
打ち合わせの品質を向上すれば、業務全体の生産性は間違いなく上がるでしょう。

下記のようなテーマに沿って話せれば良いなと思っています。
例)

• しっかりとした準備が前提。
• 打ち合わせにはいくつかの性質があり、性質を把握して立ち振る舞いを調整する。
• 前提を合わせることにコストを惜しまない。
• いくつかのオプションと撤退ラインを明確にする。
• 情報の粒度やステータス、用語に細心の注意を払う。