どうですか？社内イベント、開催してますか？

エンジニアとして生まれたからには様々な社内イベント開催のチャンスがあるかと思います。
LT会や勉強会、輪読会や懇親会……

でもどうやって開催したらいいんでしょう？何を、いつまでに、どのように進めたら？当日はどうする？

本セッションでは、私が社内イベントの運営や司会進行を数年務めてきた中で、
得たノウハウや個人的に大事にしている価値観についてお伝えできればと思います。
皆で楽しく円滑な社内イベントを作り上げていきましょう！

ぜひ聞いてほしい方

• 社内イベントを開催してみたいけどどうしたらいいかな……と悩んでいる方
• 社内イベントを開催しているけどなかなか上手に進められない方

※トーク内容の大半は社内/社外を問わないものとなりますが、
社外イベント特有の観点について扱わないため今回は「社内イベント」に限定します

フレームワークのドキュメントに従って、あるいはプロジェクトの既存のコードに従ってファイル上部に書いた「namespace」「use」といったキーワード。

この意味、正しく理解していますか？
「ディレクトリ名と対応させて書くやつ」「他の言語でいう import みたいなやつでしょ？」みたいな認識をしていませんか？

実は PHP の機能としては namespace（名前空間）とディレクトリ名、ファイル名には一切の関係はありません！

「じゃあ、なんで require とかを書かずに他のファイルに定義したクラスを使えているの？」と思ったあなたに、その仕組みと、それらを支えている存在をお教えします。

※本トークは「第 146 回 PHP 勉強会@東京」にて発表した LT の改訂版です。

Google Apps Script（以下、GAS）とはGoogleが提供するローコードプラットフォームです。
単なるJavaScript実行環境にとどまらずGoogleの提供する各種サービス（スプレッドシートやフォーム等）との連携を容易に行えたり、動的なWebページを表示できたりと、まさに「ローコードプラットフォーム」と呼ぶにふさわしい機能を備えています。

何が正解かわからないビジネスの世界において、誤った方向性でプロダクトを作り込んでしまうことを避けたいもの。
そのためにコストをかけずにプロトタイプを作って仮説検証のサイクルを回す必要がありますが、GASの備える特性はその際の強力な助けとなります。

本トークでは、その際に知っておくと役に立つ

• GASでできること
• GASを使うときのコツ、Tips
• GASの限界、使うべきでないところ

についてお話します。

コロナ禍をきっかけとして、テレワークを導入した企業は珍しくないでしょう。
テレワークは働きかたに様々な利点をもたらしてくれた一方で、新たな問題をもたらした側面もあります。

私たちのエンジニア組織は従業員どうしの関係性や勉強会等の活発さといった文化を強みのひとつとしていました。
そして、テレワーク導入直後にはその強みがほとんど見えなくなっていたのです。
もともと組織文化醸成の役割を担っていた「開発組織活性チーム」は、この問題に対して活動内容をテレワークに適応させるための試行錯誤に舵を切ります。

本トークではそこからおよそ 2 年にわたる「開発組織活性チーム」の取り組み内容と、それによって実現できたこと、できなかったことおよびそれらの考察をお話します。

「システム移行の際に、リリース後に不具合が発生した」という苦い経験をお持ちの方は多いのではないでしょうか？
特に、影響範囲が大きい機能に手を入れると、不具合の規模も大きくなってしまい、後始末に追われることになります。

影響範囲を狭めて段階的にリリースするための手法として「レガシーミミックパターン」というものがあります。
弊社においても直近の開発で採用し、かなりの安心感を得られたので、知見を共有したいと思います。

開発概要

• メール送信の機能がフレームワーク標準のものではなく独自拡張されていました
• これをフレームワーク標準のものに戻すための開発をしました
• しかしメールは 50 種類ほどあり、不具合が起きるとメールの再送などの後始末が大変そうです
• そこでレガシーミミックパターンを採用し、メールの種類ごとに新旧版を切り替えられるようにしました

Macユーザーの皆様。Docker環境はどうされておりますか？
Rancher Desktopですか？Docker for Macですか？

そこでOrbStackをおすすめしたいです。MacのDocker環境の遅さに悩まれている方に最適です。
このLTではOrbStack( https://orbstack.dev/ ) のメリットデメリット、最新の情報の追い方を説明していきます

日々のチーム開発のスループットを上げる取り組みを紹介していきます！

会社でのプロダクト開発では複数人のチーム開発で進めている方が大多数だと思います。
皆さんはチーム開発で何か課題を感じたり、もっと開発のスループットを上げたいと思ったことはありますか?

弊社ではスクラム開発を採用していますが自分が今いるスクラムチームでどんな課題があったのか、 それをどのように解決してスループットを向上させていくのか
試行錯誤して徐々に改善をしていった事を話します。

「ユニコーン企業のひみつ」「チームトポロジー」の翻訳もあり、エンジニア組織の形態についての発信が増えたと感じます
主にはシニアテックリードやCTO・VPoEの視点からの、組織全体レベルでどうデザインするか？が多いですよね

コミュニケーションやチームに関する課題は、もっと卑近な単位でも発生します
仕事をうまく行かせるための大〜小の組織づくりについて、学んでみませんか？
「組織パターン」は、発売は10年ほど前ですが、組織に関する知見がパターン・ランゲージ形式で纏められた1冊であり、多くのヒントが得られるはずです

本トークは「ちいとぽよりも小さく、明日から使える組織づくり」を主眼に、書籍の内容・使い方を、実際の活用経験を交えて紹介します

対象

• 全体までは見ていないが、組織について考えている人
  • チームリーダーやEMなど

複数のテーブル構造を1つの集約として一括で取り扱うことができるRepositoryパターン。
Repositoryを呼び出す側からは複雑なテーブル構造などを隠蔽できるため、綺麗に実装できます。
ただし、当然ながらRepositoryパターンでは1オブジェクトに対して1回保存処理を行うので、クエリもオブジェクトの数だけ発行することになります。

画面から1つのオブジェクトを保存するだけであればパフォーマンスとかは気にしなくてもいいのですが、
例えば、CSVで一括登録する処理だったり、キューに溜まったものを深夜に処理するバッチのように、
大量のオブジェクトを登録する場合はクエリ発行回数が多くなってしまい、処理パフォーマンスは下がってしまいます。

そこで、本発表では、Repositoryパターンで綺麗に処理を書きつつ、一括保存をするためにやったことを紹介しようと思います。

勉強会とかカンファレンスに何回か参加しているとそのうち湧き上がってくる感情があると思います。
それは、自分も登壇する側に立ってみたい！

でも、
発表には憧れてるけど、発表することがない。
自分なんかが発表したって誰にも刺さらないでしょ？
発表したいけど発表ネタが浮かばないから、手を挙げられない。

その一方で、いつも登壇してる人がいるし、なんなら勉強会が決まった後にネタなんて考えればいいでしょ？って人もいるんです。
同じようにネタがないのに発表できる人と発表を尻込みしてしまう人、この違いはなんなんでしょうね？

そこで、ネタがなくて発表を尻込みしちゃっていた自分が、発表ネタを見つけるために心がけたことを話します。
同じように発表したいけど話すネタがなくて困ってる方の背中を押せたら嬉しいなと思います。

アプリケーションコードや運用保守などSQLを使ってクエリを書く機会は多々あります。
皆さんはSQLを使ってクエリを書くとき、どんなことを意識していますか？
「えーっと、まずはSELECT句から書いて…」
簡単なクエリを書く分にはそれでも良いですが、複雑なクエリを書かないと目的が達成できないような状況だったらどうでしょうか？

当LTでは複雑なクエリを書く上で必要な観点について話していきます。
具体的には以下のことについて解説していきます。

• ベン図を意識しよう
• 複雑なクエリは複数のクエリの塊なので、一つ一つのクエリを動作確認しながら進めよう
• SQL実行順序に沿ってクエリを書いてみよう

ある程度ゆるくコードがかけてしまうのもPHPの良さ。
しかし、キャリアを進めていけば必ずテストや静的解析で品質を担保する機会はやってきます。

「テスト書け！話はそれからだ。」「PHPStanのレベルは5以上な」
急に上司から命じられ、ゆるふわPHPerは愕然とすることでしょう。

本LTでは、テストを書くこと、静的解析がプログラムの品質にどうメリットがあるのかに加え、
それらがゆるふわPHPerの開発者としてのキャリアにもたらすメリットについてもお話しします。

結論、テストと静的解析はいいぞ、になるのですが、世の若手が
なるべく負荷なく自主的にテスト、静的解析したいぞ、となるLTにします。

対象者
PHPUnitやPHPStanをなんとなく触っている若手
全く触ったことない初心者
とりあえずテスト書けで終わらせちゃうシニア

話さないこと
細かいPHPStanやPHPUnitの書き方

みなさん、テストを“書かされて“いないでしょうか？

私は以前、テストコードに対する苦手意識が高く、テストコードも合わせてリリースするルールがあるから書く、という気持ちで書いていました。
約1年間抱いていた苦手な思い、なんと丸一日で（ほぼ）なくなりました！
やったことは、テストコードのペアプロです。

• ペアプロ中に意識して取得した知識
• 苦手意識がなくなったことで得たメリット

をお話しします！

皆さん開発を楽しめて進められていますか？
現在開発周りではCI/CD、テストコード、デプロイ自動化など多くの生産性を高める技術というのが多いと思います。
ただし、慣れてない方にとっては最初の一歩はとてつもなく大きいと思います。

本トークでは、そんな慣れていないときの最初の一歩を踏み出すための心構えに関して話したいと思っています。

▼対象者

・何かの改善をしてみたいが思いつかない方
・提案するのが怖い方

▼話すこと
日々の業務や開発プロセルに関して下記のようなことを話す予定です。

・どういうところに「カイゼン」ポイントがあるか
・改善する時の観点について

※諸事情により参加できなくなったため、プロポーザルを取り下げます。申し訳ありません。

Fiber は、PHP 8.1 から導入された stackful な coroutine です。
ここで一度、Fiber の実装を PHP の処理系レベルまで追いかけることで、Fiber が何であるか、そして、裏で何をしているのかを理解することにしましょう。

主な対象

• 非同期処理の内部実装に興味があるかた
• 言語処理系の内部実装に興味があるかた

話すこと

• PHP における「Fiber」とは何か
• PHP の VM (virtual machine) のおおまかな構造
• Fiber を実行・停止・再開・中断したとき、PHP VM に何が起こるか

話さないこと

• Fiber を裏で利用するライブラリやフレームワーク

※諸事情により参加できなくなったため、プロポーザルを取り下げます。申し訳ありません。

Garbage collection (GC) とは、確保したメモリ領域を適切なタイミングで解放する仕組みのことです。
メモリが比較的潤沢になった今でも、メモリ溢れによるサーバ障害は決して珍しくありません。
PHP における GC を理解し、メモリを意識したプログラミングをすることで、本番サーバを夜中に落とさないようにしましょう。

主な対象

• 普段メモリを意識してプログラミングしていないかた
• 言語処理系の内部実装に興味があるかた
• メモリ溢れで本番環境をダウンさせたことのあるかた

  話すこと

• PHP における GC のアルゴリズム
• 確保したメモリはいつ解放されるのか
• メモリ溢れを起こさないプログラミング

  話さないこと

• GC のパラメータをいじってチューニングする

REST API を利用したり機能追加するときに、こんなことを思ったことはありませんか?

・必要なリソースを取得するために複数の API を実行しないといけない
・機能追加に伴って API のエンドポイントが増えて管理が大変

GraphQL を利用すると、クライアントが必要とするリソースだけを 1 回のリクエストだけで取得できます。
さらに、 GraphQL のクエリに、クライアントが要求するリソースの情報が記載されているため、従来の REST API のように、必要と思われる分だけエンドポイントを用意する必要もありません。

本 LT では、 Laravel と GraphQL を使って、 API サーバーを構築する方法を紹介いたします。
GraphQL に興味があるけれど触ったことがない方々に、始めるきっかけとなれば幸いです。

不正アクセスが怖くて夜しか眠れない、情報流出のニュースを見るたび不安で寿司しか喉を通らなくなる、
Webエンジニアはこういった日々を過ごしていると思います。

このセッションではLinuxの機能 AppArmorを用いて、PHPアプリケーションのセキュリティを外側から強化する方法を紹介します。

自分達が書くPHPコード自体の脆弱性だけではなく、フレームワークやライブラリ、またHTTPサーバー自体の脆弱性もカバーできる便利な機能です。
OSの機能でアプリケーションに対してファイルシステム・ケーパビリティ等の制限ができ、設定ファイルを用意すれば使えるため採用の手間も大きく有りません。

お客様のデータを預かるWebサービスでは信頼が第一、まだ使われていない方も使おうと思えるよう、具体的な設定例も踏まえて説明できればと思います。

【想定対象】
バックエンドエンジニア、インフラエンジニア

皆さん、毎日デプロイしたくないですか？＼ した〜い ／

私たちのチームではふりかえりをした結果「毎日デプロイする！」という目標を立てました。

そのためにタスク分解とタスクの順番を工夫し毎日デプロイする体制に変えました。
そうすることでチームの意思疎通が以前より楽にとれるようになりました。

本トークでは自分たちのチームでやっていた工夫・訪れた良い変化をお話しします。
毎日小さくデプロイする魅力をお伝えします！

「良いプロダクトを作るためにもっとエンジニアとビジネスサイドで協力していきたい！！」
その想いを胸に半年前からスクラムを使ってプロダクトを作っています。

それまではエンジニアとビジネスサイドが同じチームで深く関わって仕事をすることがあまりありませんでした。
スクラムを入れる上でコミュニケーションの取り方をガラっと変えたかったのですが、ちょっとハードルが高いかもな、、と感じました。

そのため最初は敢えて「不完全」な形式でスクラムを始めました。
スクラムの良さをチームで実感するにつれて、徐々に「完全」なスクラムになっていきました。
そして今は「チーム全員で良いプロダクトを作っている」という感覚があります。

本トークでは、どのようにスクラムの体制を改善していったのか実体験をベースにして紹介します。

このトークの対象

• スクラムに興味がある人
• 組織的な課題でスクラム導入に悩んでいる人