トーク

主に非エンジニア、WEBディレクターや初心者向けのセッションです。

対象:
• WEBディレクター
• 企業などのWebサイト管理者
• PHPにこれから触れるかもしれない人

ゴール：
エンジニアとの要件定義内容の確認やベンダーとの会話が少しはスムーズになれたらいいな。

内容:
受託会社で働いていると、改修や運用案件で、どうしてPHPを選ばなかったの？ または、その反対にどうしてわざわざPHPにしたの？ って案件にめぐり逢います。
クライアントから相談いただく「運用しにくい」「更新が自由に行えない」といったサイトやサービスは、PHPの使われるところが間違っているのでは…と感じることが多いです。
ちょっと知識があれば、防げたかもしれない…！

非エンジニアの人に役立っていただけそうなことをお話できればと思います。

リッチなUIを実装するために多くのアプリケーションでjQueryが利用されています。
導入がしやすい、使いやすい、プラグインも豊富といった利点がありますが
DOM操作の命令的なコードはロジックやUIが複雑になると保守性が悪くなる傾向にあります。

一方で、ReactやVueなどのフレームワークは、宣言的UIにより保守性が上がりますが
学習・運用コストなど過剰な技術となるケースも少なくありません。

本トークではLaravelのMPAにおけるフロントエンドの実装手法についてお話します。
Alpine.jsを使ったUI実装を中心に、jQueryの使いどころ、ViteやNative ESMによるJavaScriptの管理、Blade連携、コンポーネント化について紹介します。
チームやプロダクトに適したアーキテクチャを選択し、より本質的な課題解決ができるきっかけとなれば幸いです。

オブジェクト指向を学ぶ私たちは、必ず一度は「SOLID原則」に触れる機会があると思います。
私も何度も学習を重ねる中で、その原則がもたらす恩恵や、守ることの重要性を徐々に理解してきました。

…ただ、「リスコフの置換原則（LSP）」だけは「これを守るとどう良いのか？」がいまいちしっくりきていませんでした。
「同じ気持ち！」なあなたに向けて、このセッションでは、以下のようなお話をします。

• LSPとは何か？よくある例と「なぜピンとこないのか」
• 実際に私が遭遇したLSP違反の具体例
• LSPと"継承"の関係性をしっかりと理解する

「なるほどLSP完全に理解した！」といってもらえるようなトークにします！

小さくコツコツ手をつけておけばよかった…そんな気持ちになることもあるかもしれません。。
日々降ってくる、マイナーバージョン・パッチバージョンの更新を適応するのはとても大事です。

メジャーバージョンがあった場合はどうでしょう？？
依存パッケージ間の依存関係があるなど、マイナーバージョン・パッチバージョンの更新と比較して、複数のパッケージの同時更新が必要だったりもします。

・composer updateのおさらい
・composer updateで何ができるのか？何が起こるのか？
・パッケージ更新のはまりポイント
・コツコツパッケージを更新していくために…

パッケージを更新するコマンドであるcomposer updateを軸に、日々のパッケージ更新のヒントとなるポイントをお伝えできればと思います！

ここ数年、私はRaspberry PiでCPUを作っています。
これは、Z80というCPUをコンピュータから取り外して代わりにRaspberry Piで作った自作CPUを取り付けて動かすというものです。

このトークでは私が作成した2つのバージョンのCPUを題材に、以下の様なことをお話します。

• 少ないGPIOで多くの信号線をコントロールする工夫
• CPUを作るというのは具体的に何をするのか
• 手配線で作るCPUと基板発注して作るCPU
• 自作CPUのデバッグ方法
• Linux上でプログラムを動かすことのメリットとデメリット
• 全てを手放して速度を得る - ベアメタル開発

このトークを聞いた方が「CPUを作るというのはどういうことか」をちょっぴり理解し、CPUやハードウェア自作が好きになることを願っています。そしてあわよくば一緒に自作CPUを楽しみましょう！

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しく、X（Twitter）ではいろいろな回答がされていました。この回答はさまざまな立場・理解からされていて、Xのタイムラインをご覧になっていた方はいまいちしっくりこなかったのではないでしょうか。

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

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

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

昨今需要が高い子どもの安全確保に応えるべく、保育・教育施設向けICTサービス「CoDMON(コドモン)」では、園児の登降園時間帯の所在確認機能を短期間で開発しました。

本セッションではプロジェクトを進行するにあたり、どの様な課題を経てリリースできたのか、以下のことに触れながらお話しできればと思います。

1. 機能の全体像とユーザーに届けられた価値
2. 毎日の数百万近い子どもの打刻データを捌きつつ
   • 複数ドメインにまたがるデータを駆使して園児の所在確認を行う複雑性
   • 他の機能群に負荷を与えないインフラの構築課題
3. 課題に対して選択したアーキテクチャとその効果
4. 開発後の保守における課題

概要: オブジェクト指向プログラミングの基本概念である「Class」と「インスタンス化」を、弊社エンジニアが後輩に教える時の例として、ポケモンを例によく用いています。
具体的には、ピカチュウをクラスに例え、モンスターボール内のピカチュウがインスタンス化され、技を使うという流れで説明のようなものです。静的変数（static）やインターフェースといった概念も、ゲームの要素を用いて理解しやすい形で説明します。
上記の内容に加えてSOLID原則などのより詳細なオブジェクト指向設計などを用いて話せるよう内容付与していき、初学者の方も、初学者に教える方も、参考になる内容です。

キーポイント:
・クラスとインスタンス化の基本概念の紹介
・インスタンス化によるコストの考察
・静的変数やインターフェースをポケモンに例えて解説
・さらにSOLID原則などオブジェクト指向設計の参考になる詳細事例

Web APIの成功は、その設計や機能だけではなく、どれだけ優れたドキュメントを提供できるかにかかっています。APIドキュメントは、開発者がAPIを正しく理解し、活用するための鍵であり、ユーザー体験とシステムの信頼性を大きく左右します。本セッションでは、モダンAPI開発に不可欠なAPIドキュメンテーションの基本的な考え方から実践的なツールの活用法、さらには継続的なドキュメントのメンテナンス手法まで具体的に解説します。

トピック:

• よいドキュメントのヒント、主要な構成要素
• Swagger/OpenAPI、TypeSpec、Postmanなど自動生成ツールを活用し、開発プロセスに組み込む方法
• ドキュメントのメンテナンスとその自動化

参加者はこのセッションを通じて、継続的にAPIユーザーに優れたAPIドキュメント体験を届けるための知識を習得できます。

皆さんは清水の舞台から飛び降りる気持ち(※)で自社サービスにAWSを導入したことがありますか？私はあります。

私が担当しているメール共有サービスのメールディーラーは2001年にローンチしましたが、すべての機能がひとつのサーバに実装されており、apacheとDBですら集約されています。

また、フレームワークを導入しておらず、ひとつのファイルにDBアクセスを行い、print文でHTMLを出力しています。

そのためプログラムの陳腐化が急速に進んでいます。

そんな「モノリシック」を地で行くサービスに、AWSを導入することになりました。

AWSを導入した目的とどのような効果があったか？また、今後どのようなアーキテクチャしようとしているかを、メールディーラーのテクニカルリーダである私が可能な限り具体的に事例をもって説明いたします。

※一世一代の決断をする意味のことわざ

皆さんはリリース後に文字化けが発生して、道頓堀に飛び込みたくなったことはありますか？
私はあります(※)。

PHP8.2の下位互換性のない修正の1つにmb_detect_encodingの文字コード検出の仕様変更があります。

私が担当しているメール共有サービスのメールディーラーで、バージョンアップ後に一部の受信メールが文字化けをしました。
原因は受信したメールのエンコード時に、前述のmb_detect_encodingを使っていたことです。

下位互換性がないPHPの仕様変更だったため、文字化けを回避することができず、
メールヘッダに文字コードの指定がないメールまで対応することになり、その対応に述べ約7人日かかりました。

メールディーラーのテクニカルリーダである私が、顧客対応で泣きをみたことを中心に苦労した経験をお話しいたします。

※実際には飛び込んでいません。

事業の成長スピードに追いつくためにスピード優先で開発した結果のコードに、このような特徴がありました。

• DBとの接続や外部サービス通信、業務ロジックなどすべてが詰め込まれている
• 何が業務ロジックで何がそうでないかが判断しづらい
• データに型がなくすべてがarrayである
• テストがない

あるとき、機能追加に伴いコードの保守性が低いことに危機感を感じてリファクタリングに踏み切り、業務ロジックの切り出しなどユニットテスト可能にしていく対応を行い、非常に扱いやすくすることができました。

このセッションでは、リファクタリング活動について、修正前コードと修正後のコードがどのように変化したのか、安全にリファクタリングを行うためにどのようなテストを用意したのか、リファクタリング活動を通して気づいたこと/学びについてお話します。

障害が起こった時には全力で対応しますよね。
障害が起こった後の再発防止までちゃんと検討してますか。

このセッションでは、再発防止のアイディアを捻り出すための方法と、それを実行に移すためのチームルールについて共有します。

例えば、アイディアを捻り出す方法には、こんなステップを踏んでいます。

1. ロジカルシンキングで原因を網羅的に洗い出す。
2. 原因を解釈する。
3. 事実や解釈に対応する再発防止策を考えてみる。
4. 良いものが出なかったら突飛なアイディアも出してみる。
5. ロジカルシンキングでマッピングして、よりアイディアを抽出する。
6. ROIを考えて実行するものを決める。

外部システムと連携を行うときに、頭を痛めるのが ”APIでの連携” です。
API で機能連携を行う場合、みなさんも一度はこんな経験があるのではないでしょうか？

「レスポンスデータが扱いづらい」
「エラーレスポンスを適切にハンドリングできない」

私たちのチームでも同様の課題に直面しましたが、
API 呼び出し時に専用の Result 型 を用意することで、解消することができました。

これであなたも、API の仕様に惑わされない実装ができるようになります。

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

さあリファインメントを始めよう
→適切なサイズに区切るには見積もりが必要だな
→見積もりの精度を上げるには何を作るかが明確じゃないと
→リファインメントが終わらない！！

リファインメントに時間がかかりすぎる我々のチームは、「リファインメントとは何か」を考え直すことにしました。
スクラムガイドの定義を調べ、実際にやっているリファインメントと比較した結果、
辿り着いた答えは「我々のリファインメントはリファインメントじゃない」でした。

このトークでは、なぜ我々のリファインメントはリファインメントではないのか、方針を変えたことでチームにどのような変化があったのかをお話しします。

さあリファインメントを始めよう

皆さんは、Laravelでの定期実行をどう実現していますか？？

我々のチームでは、サービスをECSにてデプロイしていることもあり、Laravelのタスクスケジュール機能を使わない選択をしました。

しかし、ECSのLaravelサービスに対して定期実行する方法には、以下のようなものがあります。
・ECSのスケジュールされたタスク
・Amazon EventBridge SchedulerからのECSタスクの実行
・Amazon EventBridge SchedulerとLambdaを使用したAPI呼び出し
この中から「早くて安くて安心な」手段を選ばねばなりません。
そこで、AWSのコストを抑えつつ、必要な要件を満たし、運用が簡単な方法を見つけるべく我々はアマゾン（AWS）の奥地へと向かいました。

そして冒険の果てに見つけた、最適な定期実行の方法をお話します。

DKIM、DMARC、SPF
これらを説明できるでしょうか？

2024年4月から本格的に始まったGmailのガイドラインに基づくメールの受信拒否設定によって、メールセキュリティの考慮は他人事ではなくなりました。
これは、非エンジニアにとっても同じです。
場合によっては、サービスの利用者にGmailガイドラインに対応するよう依頼する必要があるからです。

しかしながら、これらの知識はどうしても専門的な技術知識なしでは説明しづらく、非エンジニアにとってはなおさら理解しづらい分野です。
難しい専門用語を使わないよう注意しながら、非エンジニアの方に理解してもらおうと頑張って資料を用意して説明した方も多いのではと思います。

この発表では、非エンジニアの人にも伝わるよう、今押さえておくべきメールセキュリティについて解説します。

背景
あるプロジェクトでたくさんの障害を発生させてしまった。。。
障害はユーザーに迷惑をかけてしまうし、エンジニアのメンタルが削られるし、進行中のスケジュールを圧迫する。全然いいことがない。障害はこの世から無くなって欲しい。せめて減らしたい。。。
そんな思いから開発プロセスを見直す動きが社内で生まれました。

お話しすること
・そもそも障害と何なのか？障害と向き合う
・適度な障害予防コストのバランス
・プロセス確立までの道のり
・実際のプロセスや工夫を紹介

障害を少しでも減らしたい、自分のチームに見合ったプロセスをカスタマイズしたいと同じ悩みを抱えているPHPerの皆さんにお伝えできれば幸いです！

NeoVim IDE。
本セッションでは、VsCodeやJetBrains製品が提供する「統合開発環境」としての機能を、NeoVimとTUIを利用してTerminal内で表現する事であると定義します。
LSP、DAP、補完やGitにDocker操作等々のIDEとしての環境をNeoVimで構築するまでのステップと、その効率性について解説する内容になります。
皆さんに「こんな選択肢があるのか」と自分の開発環境を見直す機会になることがGoalです。

話すこと

• なぜTerminalで完結させているのか
• NeoVim IDEとIDE製品のPros/Cons
• Lua言語について
• Terminal周りのOSS事情と、Rust製の勢い
• 自分が大規模コードをNeoVimのみで編集できるようになるまでの四苦八苦
• PHPでのライブコーディング