トーク

最近、1993年発売のX68030というパソコンを買って動かして遊んでいます。
大学生当時に憧れだったけど高くてとても買えなかったX68030ですが大人になり財力が付いた今なら…と思ってフリマサイトを監視していたら良さそうな機体が出品されたのを発見してつい…。

X68030はHDDにSCSIを採用しHDD内蔵モデルであるX68030-HDには80MB（GBじゃないですよ）のHDDが内蔵されていました。

翻って現代、2022年。世の中には「Raspberry PiでSCSIデバイスをエミュレートする」とか「Compact Flashに格納したファイルをSCSI HDDとして見せる」とか「Raspberry Pi でFDDをエミュレートする」みたいな同人ハードウェアが生み出され、当時とはまったく異なる快適なX680x0環境を構築することができます。

このトークではX68030の紹介と、2022の今、X68030を楽しむにはどうすると良いかをお伝えします。
今でも十分通用するX680x0の魅力がみなさまに伝わり、X680x0ユーザが増えることを期待しています！（ねえよ）

QAエンジニア業務をやり始めて4年目になります。
大規模では、テストの自動化やQA業務の課題を可視化させてワークフローの最適化を経験し、小規模では、ワンオペによる俗人化やそもそもQA業務がマニュアル化されていないQA環境の整備するなど、様々なQAの現場でQA業務を経験してきました。
最近では、QAメンバーの採用で苦戦しており、とくにエンジニア採用で苦戦している以上にQAエンジニアやテストエンジニアがいない問題が深刻になっています。
本トークでは、QAエンジニア奮闘記と題してこれまでとこれからのフリーのQAエンジニアとして奮闘する話ができたら嬉しいです。

CakePHP 2 系のサポート終了に伴い、関わっているプロジェクトを Laravel でリプレースしました。
当時、 Laravel は触ったことがない状態だったものの、PHP のイベントを聞いて興味を持ちました。
Laravel は器用なことができるフレームワークだと感じていますが、その反面、Laravel を導入したばかりの時にはチームで決めていくことがいくつかありました。

また、 Laravel 化に合わせ、CI の拡充やインフラの整備、 PHP 8 対応なども進めたため、本トークではこれらの知見の共有を行う予定です。

チームで会話している時にデザイナとエンジニアでは同じ名詞に対してでも頭に浮かべているものが異なります。
デザイナはユーザのメンタルモデルを元に、エンジニアはシステム設計や要件を元に会話していることがほとんどだったので常にお互いの話が理解しにくく、デザイナをチームの中でも孤立させてしまっていました。

そのような問題を解決すべく、私のチームではエンジニアとデザイナで定期的にプロダクトに対してOOUIでのモデリングを行ってきました。
本トークではこの取り組みから以下のことをまとめて発表する予定です。

• OOUIモデリングの簡単な説明
• チーム状況と課題
• OOUIモデリングで得られた効果
• ドメインモデリングとの対比
• チームで行っていく中で感じた課題
• 副次的に得られた効果

PHPでも型を付ける事で不意なバグを減らしながら、快適にプログラミングする事ができる静的解析ツールが開発されています。
また、PHPのヴァージョンが上がるにつれて型に関するサポートも充実してきており、現代のPHPは、昔のPHPの印象で語られる世界とは別の世界と言っても過言ではないでしょう

他の言語でも型システムが強力なしくみが導入されたり、強力な言語が話題になったりしていますが、フロントエンドフレームワークと通信する時など、言語を跨いだ型情報の共有に便利な仕組みがquicktypeです

PHPはquicktypeでの対応が現時点では無いのですが、有効に利用するための工夫を纏め発表します。

フルサーバーレスな構成を取る場合、必要な様々なクラウドサービスの知識に加え
実践的な利用方法が求められます。

フルサーバーレスの恩恵を受けたいが、その第一歩が難しい。
その悩みをAWS Amplifyは解消してくれます。

AWS Amplify で出来ることをご紹介しながらReact + GraphQLで作成するログイン付きの
サンプルWebアプリケーションを作成する流れについてご説明します。

具体的な手法をなぞることで、
どの様にフルサーバーレスなアプリケーションを作成するかを学びましょう！

• 想定する聴講者
  • フルサーバーレスアプリケーションに興味がある方
  • 具体的なフルサーバーレスアプリケーション開発の始め方を知りたい方

推測するな、計測せよ
パフォーマンスチューニングの文脈でよく使われる格言です。

ではこの格言を実際に実行するにはどの様な手法をとるべきなのでしょうか。

一言に計測と言っても、Webアプリケーションには
Webサーバー、アプリケーション、データーベース、フロントエンドと様々なレイヤーが存在します。

今回はWebアプリケーションを計測する第一歩を進める為に必要な手法についてお話します。

アプリケーションを計測する手法を知ることで、アプリケーションが内包している問題を見つけ、さらなる改善を進める一手にしましょう。

• 想定する聴講者
  • なぜ計測するのかを知りたい方
  • Webアプリケーションを計測する手法について幅広く知りたい方
  • N+1問題、DBパフォーマンス等の課題を抱えている方

Webアプリケーションはどうして動くのでしょうか。

ブラウザ等のクライアントから送信されたHTTPリクエストを契機に、
Webアプリケーションでは様々なレイヤーでの情報処理が行われます。

今回はその情報処理の流れをLaravelを例に追うことで、
Webサーバー、Laravelアプリケーション、データーベースと
レイヤー毎で行われている処理とそのレイヤー毎のつなぎ込み部分に迫ります。

HTTPヘッダーを含むHTTPリクエストの流れを追って、真にWebアプリケーションがどうして動くのかを知り、
必要な処理をどこに組み込むことが効果的なのかを知る一助になれば幸いです。

• 想定する聴講者
  • HTTPリクエストからレスポンスまでの流れをよく知らない方
  • HTTPヘッダーについて知りたい方
  • ウェブアプリケーションにおけるレイヤー毎の役割を整理したい方

毎日流れてくるエラーに皆さんはどう向き合ってますか？
エラーを出さない事が一番ですが、完全に塞ぐ事は難しいと考えます。
サービス運用の中で本番環境から発生するエラー（サーバー・クライアントサイド・サードパーティ起因のエラー）への監視体制と、
エラー・バグ防御のためチームで行っているテストコード文化づくりの話をします。

• sentryを使ったエラー監視体制
• エラー種類の集計
• チームでテストコードを書くために
• カバレッジ向上へ向けた施策

【トーク対象】

• webサービス運用エンジニアの方
• いまいちサービスのエラーを把握しきれていない方。知らないふりしている方。
• テストコード書いてない方。書きたい方。
• 明日なんとかしよう、、と思って数ヶ月経っている方。

コロナ禍でリモートワークになったエンジニアは数多くいらっしゃる事と思います。
そろそろ2年が経とうとしていて、少しずつリモートワークに慣れてきても、やっぱりオンラインとオフラインの差はある。
それぞれのメリット・デメリットを認識した上で、ワークライフバランスを上げつつ仕事を進める方法を、リモートワーク経験20年超&フルリモート転職の経験を踏まえてお話したいと思います。

2018年のGitHub UniverseでGitHub Actionsが発表されてから約3年、今ではGitHubを代表するなくてはならない機能の1つになっています。

発表者もv2（not HCL）から使い始めており、作成したOSSのCI/CD環境として有効に活用するだけでなく、独自に作成したActionもいくつかGitHub Marketplaceに公開しています。

本発表では「PHPで独自Actionを作成する」ことを通じて、GitHub Actionsを使いこなすに当たって、私の知る知見を時間の許す限り紹介します。

細かすぎて全く必要のなさそうな情報ばかりかもしれません。しかし、あなたがGitHub Actionsを使いつづけていくといつか必要になる情報かもしれません。

GitHub Actionsをより深く知ってCI/CDだけでなくさまざまな自動化効率化を実現しましょう。

依存ライブラリの更新、定期的に実施できていますか？

恥ずかしながら担当プロダクトで更新ができていないケースがありました。
そしていざ更新を試みると対象ライブラリがいくつもあり、大幅なバージョンアップが必要なものも・・・

このような状況はまずいと感じ調べたところRenovateという依存ライブラリの自動更新を行うツールを知り、導入を試みましたが、更新を怠っていたプロジェクトでの素直な導入は難しいと判断。
そこで導入までにステップを置き、ライブラリのバージョン更新・Renovateの導入、そこから定期的に更新するという運用の流れを構築し、現在はライブラリの更新が健全にできていると感じています。

本トークでは依存ライブラリの更新を怠っていたプロジェクトにRenovateというツールを導入した流れと導入後の運用状況をお話させていただき、皆様の依存ライブラリ管理の一助となればと思っております。

「DOT言語」

あまり聞くことがない言語だと思います。
ではこのように言い換えたらどうでしょう？

「Graphvizで使うDSL」

以下の検索結果をみて「何かのツールの出力でみたことがある画像」と思うかもしれません。

https://www.google.com/search?q=graphviz&tbm=isch

DOT言語はGraphvizのための言語です。
本発表は「Graphvizを使ってみたい」という方が対象です。

「難しそう」と思った方へ。

私のDOT言語のイメージは、

• DOT言語はプログラミング言語というよりHTMLのようなマークアップ言語
• HTMLをブラウザがレンダリングするようにDOT言語で書かれたコードをGraphvizがグラフ画像に変換する

です。

「PHPと親和性高そう」と思った方。その通りです。

DOT言語の世界へようこそ！

Xdebugを使うとブレークポイントやステップ実行によるデバッグができるようになります。
XdebugはDBGpという通信プロトコルを使って、IDEとデバッグ対象のコミュニケーションを行いデバッグしています。
本セッションではPHPのソケット通信を使った簡易的なデバッガーを通じて、DBGpのプロトコルやデバッガーの裏側についてご紹介します。

プロジェクトとしてSREを実施することになったので、プロダクトにSLOを定めてみました。

実際に定めた内容の他、SLOを定義するまでに至る経緯、現運用の課題や、アプリケーションエンジニアとのコミュニケーションに関する今後の展望など、弊社エンジニア組織の文化的背景など踏まえお話しします。

普段、受託の案件（特に業務システム）に携わるエンジニアだと、大量のアクセスを想定したアプリケーションを実装する機会が多くありません。
私は今回初めて数万ユーザーが利用するtoCのLaravelアプリケーションの構築に携わりました。
数万ユーザーのアクセスに耐えうるインフラ、アプリケーションを構築できたのか！？
「実際どれくらいの秒間リクエストに耐えうるのか？？？」をLocustというツールを用いて負荷試験を実施して、試行錯誤したことお話しします！

・ 想定する聴講者

• アプリケーションの負荷試験にまだ挑戦したことのない人
• 普段業務システム系が多く、大量のユーザーアクセスを想定したアーキテクチャ設計をやったことのない人
• Laravelで負荷試験の際に気をつけていきたいことを知りたい人

オンライン決済サービスStripeを利用することで、少ないコードで複雑な料金体系の定期課金や決済機能を実装することができます。
また、Webhookを利用したバックエンドシステムへの組み込みや自動化、CRMなどとの連携も難しくありません。

このトークでは、PHPの実行環境としてAWS Lambdaを利用し、以下のトピックについて紹介します。
・AWS LambdaでPHPを利用する方法（Serverless Framework）
・AWS Secrets Managerを利用した、安全なAPIキー運用
・Stripe / Stripe Webhookを利用した定期課金の実装やサービス連携方法

AWS Lambdaに限らず、
AWS上でPHPとStripeを利用したWebアプリケーションを開発する際に意識したい点やアーキテクチャのヒントについてもお話ししたいと思います。

去年、「オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)」を読みました。その中で、デザインパターンの1つ「Observerパターン」の紹介がされています。「そういえば、今まで使ってきたフレームワークの中でObserverパターンの処理があったな」「でも、微妙に記述方法が違ったな？」「それぞれの違いを比較してみたいかも！」となりました。

• CakePHPに見るObserverパターン「CakeEvent」
• Laravelに見るObserverパターン「Laravel Observer」

どのように使うのか？どのような実装がなされているのか？それぞれのいいところ・・・ナドナド、「Observerパターン」の基本的な説明も含めて、時間の許す限りまとめます！

個人で PHP 用のプロファイラを作っておりまして、これは FFI を経由して Linux のシステムコールを呼び出し、別プロセスで実行中の PHP 処理系のメモリ内容を覗き見し、内部データを解釈して実行中の PHP スクリプトの情報を盗みとる、という少し変わった PHP スクリプトです。

https://github.com/sj-i/php-profiler

2020 年から半分くらいギャグのつもりで少しずつ開発を続けているものですが、作っているうちに案外実用性が出てきてしまった気がするので、内部実装や利用方法について少しだけご紹介します。

■ 想定する聴講者

• PHP の性能計測についてちょっと変な奴でもいいから手札を増やしたい人
• PHP での低レベル寄りの大道芸が好きな人
• 年に 1 回や 2 回くらいは「PHP で何やってんだよｗｗｗ」という種類の笑いがほしい人

既存サービスにフレームワークを導入するとなると、さまざまな障壁が立ちはだかります。
導入によるコスト、品質への影響、ビジネスサイドとの合意形成など。
弊社では、リリース後21年目になるレガシーサービスにLaravelを導入しました。
このセッションでは、導入に至った経緯、ビジネスサイドとの調整、戦略、アーキテクチャ選定、導入手順とその結果や成果などを紹介させていただきます。
レガシーサービスだけど、フレームワークを導入してみたい開発者向けの内容となります。