トーク

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

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

【トーク対象】

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

php の基本の foreach 。
しっかり正しく記述できていますか？

foreach は簡単そうに見えて柔軟すぎて、結局難しかったりします。

こんな悩みはありませんか？
・foreach の中に if 文がたくさん詰まってしまう。
・Promise を foreach で回すのが難しく感じる
　・同時実行上限
　・終了時上限の付与
・Generator が苦手
　・遅延処理が書けるって聞くけどよくわからない
　・結局 foreach で終了までを全部詰め直すから読みにくくなってしまう

それらを解決する概念が下記の３つです。
・map処理
・並列処理
・遅延処理

この概念をいい感じに foreach で説明できたらいいなって思います。

コロナ禍でリモートワークになったエンジニアは数多くいらっしゃる事と思います。
そろそろ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だけでなくさまざまな自動化効率化を実現しましょう。

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

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

本発表では、GitHub Actionsを使いこなすに当たって、私の知る知見を時間の許す限り紹介します。

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

そして本発表では最終的に「PHPで独自Actionを作成する」ところまでいきたいと思います。

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

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

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

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

phpを書く人はphpstormを使う人が多いと思いますが、別のテキストエディタでも同じようなことができます。
私はemacsユーザなのでemacsユーザならではの話をしたいと思います。

具体的には以下のような話

• ファイル検索
• 文字列検索
• 補完
• syntax highlight
• LSP(DAP)
• snippetの運用
• M-x compileなどemacsの機能について
• magit

2019年11月にGAとなった Cloud Run。
それから2年となる最近、とある案件で「GCPで、Laravelアプリを」というオーダーに巡り会いました。
「AWS Fargate 上に Laravel プロダクトを載せる」ことをやりきっていた自分は、
Compute Engine ではなく Cloud Run 上に、Terraform module を利用して構築することにしました。

やると決めてから、久しぶりのGCPのインフラを、初めてIaCで構築していきました。
今のところ、順調に進んでいると思います。

このLTでは、その過程で感じてきた

• それまでに慣れていたAWSとの様々な違い
• Terraform module を利用することで手軽にクラウドインフラを組み上げることができる素晴らしさ

といったあたりの、新サービス構築試行事例をご紹介したいと思います。

「DOT言語」

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

「Graphvizで使うDSL」

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

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

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

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

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

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

です。

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

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

皆さんはPHPでの開発でPredefined Interfaces(定義済みInterface)を使っていますでしょうか？PHPにはIteratorやStringableといったシンプルですが便利なInterfaceが用意されており実装することで、独自のクラスをPHPのプリミティブな型と同様に扱うことができます。どうやってPredefined Interfacesを使うのか、どんなメリットがあるのかを解説します。

Laravel Octane（Swoole版)でPharをつかってワンバイナリアプリケーションにして運用してみた話です
過去、PHPカンファレンス北海道（２０１９）にて
「pharによるワンバイナリアプリケーションの可能性を探ってみた」
でお話ししましたが、そのリベンジ（現実版）になります
Laravel OctaneをPharで固めたときにつまづいた話を中心にお話しします！

PHPだけど、Buildして(Pharでpackして）、Deployして運用してみよう！

サイボウズの大企業向けグループウェアのGaroon（ガルーン）は、PHPで開発されている20年目の製品です。ガルーン開発チームは日本で40名、ベトナムで50名の計90名ほどのチームになっています。また、コロナ禍でフルリモートでの活動がこの2年ほど継続してきました。

フルリモートになっても仕事はまわっており、継続的にリリースはしていましたが、一方でお互いの考えていることや感じている問題意識が見えづらくなり、モヤモヤを抱えているメンバーが増えていました。

このセッションでは、そういう状況で私がチーム外からジョインし、聴き役に徹しながら見える化することで状況を改善していった取り組みを紹介します。同じように大きなチームやリモートワークで難しさを感じている人に、難しさの原因への気づきや取り組みへのヒントがあれば幸いです。

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

チーム開発って「スケジュール通りに終わらない」「コミュニケーションが上手く取れない」など、いろんな問題が発生して悩むことが沢山ありますよね。弊社での開発でも同様の悩みを抱えながら、日々開発に奮闘しています。

本トークでは、弊社のプロダクト「カオナビ」での、開発期間約１年の開発プロジェクトにおける、スクラムでのチーム開発の経験談をご紹介します。

このトークでお話すること

• どうやって開発を進めていったのか
• 立ちはだかる様々な問題に対してどうやって立ち向かったのか

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

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

さくさく開発を進めるにあたってコンテナイメージのビルドには時間をかけたくありません。
typoをなおしただけなのにvendorのインストールを待っている時間はじれったいです。

キャッシュを使って時間短縮しつつ、完成物は小さくまとめる方法を考えます。
時間があれば、継続的アップデートやLambdaで動かすPHPコンテナへの適用についても触れます。

本セッションではマインクラフトを使ってスクラムワークショップをする様子をお届けします。

ソフトウェア開発におけるスクラムはチームが価値を生み出すためのフレームワークです。
不確実性がつきもののソフトウェア開発において、その有効性が認められ、現在では多くの成功事例が存在します。
そのため、スクラムを採用したいと検討しているチームもあることでしょう。
しかしながら、スクラムはただ聞いただけでは実践するのが難しいという問題があります。

そこで活用できるのがワークショップです。
短い期間に集中して体験すれば、スクラムのフレームワークに対する理解が深まり、スクラムの実践に役立つことでしょう。
今回はそんなスクラムワークショップをご紹介いたします。
ワークショップで取り扱う題材はマインクラフトです。

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

・ 想定する聴講者

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

PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。

本講演では PHP 8.1 をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。