トーク

ここ数年、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のタイムラインをご覧になっていた方はいまいちしっくりこなかったのではないでしょうか。

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

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

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

私はEM2年生。 2024年4月に新規プロダクトをリリースし、現在はそのプロダクトをなんとか成長させていくべく邁進しています。

新規プロダクトのリリース、そしてその後の成長にあたってはさまざまな進行上の課題がチームに襲い掛かりました。

・ スクラムを解釈した開発イベントがなぜかうまくいかない
・ 社内や社外からのフィードバックが集まらない
・ プロダクトマネージャーとタスクの温度感がすり合わない
・ プロダクトの課題が無限に積まれ、さばいてもさばいてもなくならない
......

これらの課題が発生した背景には、新規プロダクト開発においてはフェーズごとに求められる立ち回りが大きく変化するというものがありました。

本セッションではそのような状況に対応するため、繰り返し見直し、変更・改善してきた開発手法の変遷について、良かった点と反省点の両軸から振り返ります。

PHPは基本的にシングルスレッドで動作します。そのため、並列処理は得意ではありません。
外部APIを複数叩くようなWebアプリケーションを作ろうと思った場合、1つずつ外部APIのレスポンスを待っていたのでは、処理完了に時間がかかりすぎてしまいます。

PHP製のHTTPクライアントライブラリであるGuzzleでは、非同期リクエストがサポートされており、複数のHTTPリクエストを同時に投げることができます。

並列処理が苦手なはずのPHPで、なぜそんなことが可能なのでしょうか？
このセッションではGuzzleのソースコードを紐解きながら、非同期リクエストがどのように実現されているのか、Guzzleに何ができて何ができないのかを見ていきます。

古くなったプロダクトのコードをリファクタリングしようとして、逆に障害を招いてしまった。そんな経験を何度かしてきました。
特にPHPでは、なんとなくコードを変えただけで、思わぬところが壊れてしまうことも少なくありません。

今回は、そんなPHPリファクタリングでの失敗談を、びゃっと5分でご紹介します。
このトークが、みなさんのしくじりを防ぐヒントになれば幸いです。

PHP8へのメジャーアップデートに挑戦した際、PHPUnitのメジャーアップデート対応など、久しぶりにPHPを触るにしては越えるべきハードルが複数ありました。
ハードルを越えるためにCursor / Claudeを活用して調査や試行錯誤を試みた際の経験を紹介します。

私が担当しているメール共有サービスのメールディーラーは2001年にローンチしましたが、
プログラム構造の陳腐化がリリースを行うごとに進み、いわゆる「スパゲッティコード」が散在し、
それらがサービスの品質にまで影響するようになりました。

具体的には、ある共通関数が別の共通関数を呼び出し、
それが繰り返されることでプログラムが複雑にネスト化しています。

その結果、コード全体の把握が難しくなり、思ってもみない機能に不具合が混入し、
新機能のリリース直後に改修していないはずの機能が動作しなくなる致命的な障害が発生しました。

これらの対策としてE2Eテストを導入しそれを自動化しました。

E2Eテストを導入したことで、致命的な障害が防げたか？など得られた効果や
テストコードの実装やテストケースの作成における工夫ポイントなど、可能な限り具体的に説明いたします。

私が担当しているメール共有サービスのメールディーラーは2024年10月に「AIクレーム検知オプション」をリリースいたしました。

開発に当たり、メールディーラーで初めてβ版をコンテナで構築し、
お客様にご協力をいただき、ChatGPTで判定しているクレーム検知の精度向上を行いました。
そしてコスト削減や負荷分散を狙い、製品版をAWSで構築することで、
クレーム検知の精度を実用レベルまで向上させ、約65%のコスト削減に成功しました。

AWSやコンテナは新しい技術ではありませんが、メールディーラーは全機能が一つのサーバに実装されており、
WebサーバとDBがひとつのサーバに集約されているため、導入には苦労しました。

AWSの導入にあたって、どのように目的を整理し、利害関係者を説得したのか？どのようにして目標を達成したのか？
可能な限り事例を交えて説明いたします。

新卒から6年間所属した部署から大異動で全く別のチームに配属された先では、PHPを使ったアプリケーションを開発、運用していました。
ただ、チームの状況を見てみると鳴り響くアラートの対応に疲弊していました。
異動先のチームには、以下のような問題を抱えていました。

• アラートの詳細を詳しく見なければ問題がないことを判断できない
• アラートの判断は属人化している
• 問題ないアラートが飛び続けている
• 最初に監視を設定した人はすでに社内におらず、意図がわからない
• 調査から対応するまでのリードタイムが長い

これらに対して、一つ一つ向き合って出してきた答えについてお話します。
聞いて欲しい方

• 新たに配属されたが、アラート対応ができなくて悔しいと思ってる人
• アラート対応に課題感を持っている人
• アラート対応が属人化しないようなアプリケーション設計、チーム作りをしたい方

想定聴講者

• センシティブな値を扱うシステムの開発をしている人
• テストだけでは挙動の担保に不安で、リファクタリングに踏み切れない人

話すこと

• 安全にリファクタリングする方法
• テスト以外で挙動が変わらないことを担保する方法

説明

私たちの会計システムには、取り扱いを誤ると大きな問題につながる金額などのセンシティブな値が存在します。
これらのコードのリファクタリングは安易に手を加えるには不安があり、例えテストがあってもなかなか手をつけられません。

本セッションでは、私が実際に行った"安全な"リファクタリングの手順とその方法についてお話します。

WordPressはPHPで動作するOSSの1つで、多くのウェブサイトにて現在も利活用されています。しかし多様化するウェブサイトの要件に対応するため、プラグインやfunctions.phpへのコード追加による複雑なカスタマイズが施され、保守性が悪化しているケースも少なくありません。

「コンテンツを快適に発信できる場所」というCMS本来の力を活かしつつ、アップデートの手間やアプリケーションの複雑化による負荷増加などを回避するための方法として、「クラウドサービスへのオフロード」を提案します。

セッションでは、AWSやCloudflareなどのサービスが持つフルマネージドな機能を活用し、大規模なウェブサイトの構成をシンプルかつアップデートしやすい形にする方法を、「サイト内検索」「検索エンジン最適化」「アクセス集中対策のトレードオフ」の3点から紹介します。

継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインは、昨今のソフトウェア開発ならびに運用・保守で広く普及するようになり、開発プロセスやセキュリティ対策を最適化させる上で欠かせないものになっています。一方、CI/CDパイプラインの使い方によっては攻撃者に標的にされてしまうケースが出始めています。

本トークでは、開発者の生産性を向上させるCI/CDツールとして広く利用されているGitHub Actionsで考慮すべき脅威やセキュリティ観点を解説し、保護策を検討する際のポイントや、ワークフローの改ざんおよび不正実行の防止に役立つツールを紹介します。GitHub Actionsにおける脅威や攻撃手法の対策を踏まえた上で、改めてGitHub Actionsのセキュリティを点検してみましょう。

純粋関数(pure function)という言葉を聞いたことはありますか？ 簡単にいうと、同じ引数を渡せば必ず同じ結果を返す関数のことで、しばしば数学的な関数とも説明されます。

同じ引数で同じ結果ということは確実な再現性があるということで、「純粋」の概念を知って純粋と不純な処理を切り分けられれば、コードを見通しよく、テストしやすいコードにすることもできます。

言葉をトークでは「純粋」および「副作用」という概念について学び、コードを改善するための手掛かりを学びます。

ソフトウェア開発で、「モデル」という概念が使われるようになって数十年。モデルに関する解説も世に多く出ています。皆さんの慣れ親しんだフレームワークでも、モデルという要素が普通に存在し、日々の開発で使っているかと思います。

ところで、モデルって何なのでしょうか？ 概念？ ビジネスロジック？
これらはモデルの用途ではありますが、すべてではありません。
モデルが真に力を発揮するのは、自分でモデルを設計したときです。

このトークでは、よくある予約システムを例に、素朴な設計のモデルからひと工夫加えた設計を行うことによって小さなブレイクスルーが起きる過程を具体例を用いながら説明し、聞いている方にモデルの設計のパワーを追体験して頂きます。

このトークを通じて、聞いている方のモデルについての理解をアップデートし、ソフトウェア開発に登場するモデルに関する諸問題を柔軟に取り扱えるようになって頂きます。

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

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

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

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

「自分も何か書いてみようかな」と思ってもらえるきっかけになれば嬉しいです！

開発が終わってしまったテストフレームワークをリプレイスした事例を元に、技術的負債にどうやって戦ったのかを紹介します。

トーク内容（予定）

• 具体的な課題
  • 開発終了したフレームワークがもたらしていた具体的な課題（メンテナンスコスト、実行速度、新機能への追従困難など）
• 立てた戦略
  • 段階的移行か一括移行か、手動か自動か
• リファクタリングツールの検討
  • rector の紹介
• 得られた成果

最近弊社ではmcpというワードをちらほら見かけます。
そうだ、phpでmcpを作ってみよう！
でも、phpにはmcpのsdkがありません！！😨

mcpとはなんぞや？から、どういうことをすればmcpができるのか？

※まだ何も着手していないので、どこまで紹介できるかわかりませんが
全力でphp&mcpについて紹介したいと思います！

数ある Symfony コンポーネントの中で、私が一番好きなのが ExpressionLanguage です。
私が関わる PHP のプロジェクトでは ExpressionLanguage を多く使っています。

とても便利で使い勝手の良い ExpressionLanguage ですが、情報が少なく、活用事例はほぼ皆無です。

みなさんにもっと ExpressionLanguage を活用してほしい！ということで、使い方や勘どころを活用事例を交えて紹介します。

本格的な DSL (Domain Specific Language: ドメイン特化言語) システムを作るのはかなり大変です。
でも、簡易の DSL システムであれば、ExpressionLanguage と YAML で簡単に構築できます。

DSL システムを構築することで今まで見えなかったものが見えてきます。