トーク

私は学生時代から個人開発をはじめ、社会人エンジニアとなった今でも個人でWebサービスを開発・運用し続けています。

その中で一際思い入れが深いサービスが「National Economy Online」です。当時はコロナ禍がちょうど始まった頃で、物理的な交流や遊びができなくなってしまい退屈な生活を送っていました。ボードゲームが趣味の友人とリモートでも楽しく過ごすため、「ナショナルエコノミー」というボードゲームがオンラインで遊べるものを開発しました。今では友人だけでなく多くのユーザーに何千回と遊んでもらっています。

個人開発を通して習得できる技術や審美眼、また実際にPHPでボードゲームが遊べるWebサービスを作る際のテクニックについてご紹介します。

cf.) https://speakerdeck.com/arthur1/hatena-engineer-seminar-number-28

以前「心理的安全性の育て方」という記事を書きました。
https://tech.innovator.jp.net/entry/how-to-promote-psychological-safety
一読して、「わかる」と思われた方も「そうは言っても」と思われた方もいるのではないでしょうか。

このトークでは、中原淳さんの書籍『「対話と決断」で成果を生む 話し合いの作法』をベースに、
チームのメンバーの相互理解を深めるための「対話」と「決断」をどう進めていくべきか、私自身の体験も交えながらお話しします。
実は私たちは、正しい「話し合い」のやり方を習ったことがないかもしれません。
でも大丈夫、今からだって学んでうまくなれるようにしていけばよいのです。

「プレゼンの極意を伝授してやる」というお話ではありません。
ただ「傍目八目」とはよく言ったもので、PHP カンファレンスをはじめとする技術系のイベントに参加してトークを拝聴していると「このあたりを意識すれば、もっと素敵な発表になるのではないか」と思うことがよくあります。

時間をかけて念入りに支度し、伝えたいことをたくさんの人に聞いてもらうせっかくの機会ですから、話し手にとっても聴き手にとってもより有意義なものにしたいと思いませんか。

準備と本番において頭の片隅に置いておくとより魅力的なセッションにつながるかもしれない8つのことがらを厳選してお伝えします。

皆さんはPHPサーバーのセットアップをどのように行っていますか？
手動で行う方法、構築済みサーバーを利用する方法、コンテナ技術を用いる方法など、様々な方法があると思います。
しかし、これらの方法は時間がかかったり、手順が複雑であったり、構成変更の柔軟性に欠けたりすることがあります。

今回紹介するのは、Ansibleという強力な構成管理ツールを用いた、PHPサーバーの構築・デプロイメントの自動化です。
AnsibleはSSH接続によってエージェントレスで動作し、軽量で学習コストも低いため、PHPサーバーの環境構築に最適なツールです。

このセッションでは、PHPエンジニア向けに、柔軟な構成で効率的にPHPサーバーを自動構築する手法についてお伝えします。

主な対象
PHPサーバーの環境構築に興味のある方
インフラ・DevOpsに興味のある方

技術選定で「何を選べばいいかわからない」「何が適切なのかわからない」など悩む方も多いのではないでしょうか。私自身もたくさん悩んできました。
一介のエンジニアとして開発に携わった経験，エンジニアリングマネージャーやテックリード，CTO 経験など多くの屍を超えて辿り着いた結論は「答えがない」です。それは，事業のフェーズ，ビジネスモデル，既存プロダクトの状態や既存のエンジニア組織の性格など技術選定において必要なパラメータが多岐に渡るためです。
それでも，技術選定を進めなければプロダクト開発はもちろんのこと，圧倒的な事業への成長に貢献できません。
では，ハードシングスを必要とするようなシーンの技術選定は，どのように行っていけばよいのでしょうか。
本トークでは，どういう視点で技術選定を行えばよいのかを皮切りに，様々な事業の状況を仮定しながら最適な技術選定に近づけるためのノウハウについてお話します。

アプリケーション開発で、単に要求に答えるための開発をするだけでなく、
データ分析に関する知識や幅広いドメイン知識が必要となる機会も多いのではないでしょうか？
このセッションではドメインイベントの理解がアプリケーション開発において中心的な役割を果たすかを探求します。

この概念を踏まえることで、分析の段階から境界づけられたコンテキストを明確にし、
如何にデータ分析設計やシステムアーキテクチャの進化に寄与するかを解説します。

このセッションでドメインイベントを中心とした考え方を得ることで、
柔軟なシステム設計・ドメイン理解のための洞察力を養い、
ビジネス要件の迅速な変更に対応し、継続的な成長と進化を実現するアプリケーションの開発が可能になるかもしれません。
発表では具体的な事例とともに、ドメインイベント中心の技術がもたらす可能性についても深く掘り下げていきます。

配列は、柔軟なデータ構造で便利である一方、使い方を間違えるとしばしば不具合の原因となります。

配列は==や===を使って比較することができますが、例えば ['a' => 'aaa', 'b' => 'bbb'] と ['b' => 'bbb', 'a' => 'aaa'] の比較では、 == ではtrueに、===ではfalseになります。

このトークでは、PHPが配列の等しさをどう扱っているのかをphp-srcを読み解きながら深掘りしていきます。

みなさんはFormRequestのルール部分のUnitテストを書いていますか？
dataProviderに全てのケースを洗い出し、それを使っているのをよく見ますが、
なんか違うんだよな〜と思ったことはないでしょうか？

このトークでは、FormRequestのテストをより快適に書くやり方について、
実際のコード例と共に説明いたします。

話す内容

• 既存のテストの良くないところ
• FormRequestのテストをより快適にかくやり方・コード
• このやり方を採用したことでどう良くなったのか

フロント側のテストって何を書いていいかわからない、UI部分のテストって書くのが難しそう、と思ったことはないでしょうか。

私はすごく難しいんじゃないかと思っていました。

そこでフロント開発の自動テストについて調べて、実際に作成した時、こんなライブラリやツールを使ってこんなテストをしたよ、っていうようなことを話したいと思います。

具体的には以下のような内容を話す予定です。

•Storybookを使った自動テストの作成
•Jestを用いたテストの作成
•Chromaticを用いたUIの変更点のテスト作成
•Codecovを用いてコードカバレッジを取る

ピクシブではドメインごとにクロスファンクショナルチームを事業部体制として構築し、会社としてのミッション達成を目指しています。
そういう環境で、2018年よりエンジニアギルドというエンジニア職の単一職能の横断体制を敷いて、事業部横断でエンジニア全体としての採用・評価・育成を同じ思想で強化していく活動を進め続けています。

わたしはその活動をとくに中心で、ときに一歩引いたところから推し続けてきたのですが、実現されるエンジニアリング強化とは事業を実現するケイパビリティの一つとして捉えており、またエンジニアひとりひとりの成長したい意欲を後押しすることも仲間同士で実現していきたいと常々考えていました。

5年ほど運用してきて再現性もあると考えたため、このカンファレンスの機会でこの知見をお伝えすることで、業界全体としてのエンジニア成長の加速の一助になればと思います。

「プログラマが知るべき97のこと」「ソフトウェアアーキテクトが知るべき97のこと」「スクラム実践者が知るべき97のこと」など、「97」というマジックナンバーを使った名著が10年代初頭から20年代にかけて出版されてきました。

2011年頃に当時の「IT勉強会」によく参加していたエンジニアたちが ぼっちが懇親会でするべき97のこと という大喜利を当時のTwitterで繰り広げ、 まとめが今でも残っています https://togetter.com/li/140804
それから10数年、令和の時代になって、エンジニアたちも取り巻く環境も大きく変わりましたが、まだまだコミュニケーションの不安感は人々の間にあり続けています。

その大喜利の一員として、また参加者・登壇者・開催者・企業側スポンサー担当者・技術広報など様々なロールを体当たりで担ってきたものとしての、カンファレンス参加戦略をお話します。

わたしは、かつてPHPカンファレンスやRubyKaigiなどで技術発表を行ってきましたが、近年ではこのカンファレンスのスポンサーも務めているピクシブという事業会社全体の制度作りの一翼を担ってきました。
ジョブチェンジをしたわけではなく、ソフトウェアエンジニア及びその分野のマネジメントの経験から設計スキルを武器として活用しています。

このセッションでは、わたしが実際に行った取り組みをもとに、それらの背景、思考プロセスを紹介し、今後のキャリア選択のフロンティアとしての発展像を示します。

なお取り上げる事例は以下を想定しています。
https://inside.pixiv.blog/2022/10/31/140000
https://inside.pixiv.blog/2023/02/22/115500
https://inside.pixiv.blog/2023/11/28/130000

皆さんは普段一緒に働いているチームにおいて、しばしば品質の基準がズレていると感じたことはありませんか？それがズレていると後に多大なる影響が及びます。

チームにおける「品質」が何を指していて、どのレベルになることを期待しているのかを明確にすることで、チームが同じゴールを目指しやすくなり、製品の提供スピードや品質が改善されたり、チームでの相互理解や尊敬を作るきっかけにもなります。　

今回は品質を起点とした期待値のすり合わせについて、チーム全員が期待する品質を把握するメリットを事例を交えて紹介したいです。

内容
・ チームのみんなで品質やテストに関する資料を読む
・ 開発チームみんなで品質の基準をすり合わせる
・ エンジニアと一緒にテストを作る

Webサービスの開発運用においてセキュリティは一つの重要なテーマです。CSP(Content Security Policy)はwebの標準仕様であり、クロスサイトスクリプティングやデータインジェクション攻撃などのような特定の種類の攻撃を検知し、影響を軽減するために追加できるセキュリティレイヤーです。しかし実際にこれをサービスに導入し運用をしているという事例をまだ多くは聞きません。

発表者が所属する組織においてもセキュリティ対策の一環でCSPを導入しプロダクト運用に組み込んでいます。どういった意図で導入し何が発生してそこからどういったことを学んだか、一つの事例として発表を通じて共有したいと思います。

[想定オーディエンス]

• これからCSPについて知りたいと思った方
• CSPの導入を検討しているおり、導入事例に興味関心がある方
• Webサービスの他社運用事例一般に興味関心がある方

One Line Programmingを始めましょう！

プログラムの実行というと, 作成したファイルコンパイルしたり, インタープリタで読み込ませることを想像される方が多いと思います. しかし, PHPをはじめ, 多くのプログラミング言語ではシェルに直接コードを書き込んで実行する方法
があります. 例えばPHPはphp -rを使うことで直接コードを渡すことができます.

一行では何もできない！と思われる方もいらっしゃるかと想像しますが, Shellのpipe機能などを使うことで実用的なアプリケーションを作ることも可能です.
https://zenn.dev/shundeveloper/articles/e113c189e3cc97

本セッションは「一行でプログラムを書く」ことに焦点を当てた発表です. 紹介するコードはどれも一行ですので初心者から上級者まで楽しめます！

昨今、Forteeはカンファレンスのプラットフォームとして多くの国内カンファレンスで使用されています。

また、最近では「カンファレンスに登壇やスポンサーをする」という趣旨のブログやプレスリリースが増えてきています。私も所属している企業でテックブログを執筆しています。

何回か登壇情報のテックブログを書くうちに、「Forteeから情報をコピペするのがめんどくさい」「集め終わった情報をjsonなどで保存したい」と思うようになりました。

そこでプログラムを書き、Forteeからtalk情報やog画像を取得できるようにしました。

本セッションではプログラムをどのよううに作成したかを紹介します。具体的には、プロポーザルページデータ(html)の取得、HTMLデータの加工方法についてお伝えします。

このセッションの対象者は登壇ブログを書く方や未来のFortee CLIの開発者です。

PHPはインタプリタ型言語で、実行ごとにパースとコンパイルが必要です。
OPcacheは一度コンパイルされたコードの最適化されたバージョンをキャッシュする拡張機能です。これによりPHPの実行が効率化されます。
PHP8よりOPcacheにはサブセットとしてJITコンパイラが導入され、より高速にPHPコードが実行できるようになりました。

本トークではOPcacheの概要から、チューニングの要点、監視や運用について解説します。
また、25k req/s程度を捌く大規模なPHP Webサービス環境におけるOPcacheチューニングの影響や、
特にJIT導入時のレスポンスタイムやCPU系メトリクス等についての変化を共有します。

PHPで作られたツールをいろんな環境でサクッと動かしたいと思ったことはありませんか？
Docker上で動かすことも出来なくもないけれど、色々制約もあるし、どうにかしてシングルバイナリで動かせないかな？ということでアレコレ試してみたことをトークしたいと思います。

どんなに綺麗な仕様書を書いても、コードから離れては生きられない（メンテナンスされず陳腐化して活用されない）。
そんな思いからスキーマ駆動開発でのコードとスキーマの乖離をさせないという理想を追い求めて辿り着いた開発プロセスを紹介したいと思います。
スキーマ駆動開発での悩みポイントにフォーカスし、なぜ今回のプロセスを採用しようと判断したのか？
また段階的にプロセス見直し最終的には他プロジェクトにも適用可能なcomposer化を目指したのか？についてお話します。

皆さんは､全く慣れない言語を｢今から使ってね｣と言われた経験はありませんか?私はいままさにそうです｡
コンパイラの言うことを聴いているだけで動くコードが書けるRustと違い､PHPは気をつけることがいっぱい......｡(個人の感想)
そんなPHPに不慣れな私が普段のRust開発と変わらずPHP開発ができるようになった自分なりに開発環境や気をつけていることをおはなしします｡

もしこれから全く違う言語を触ってね､と無茶振りされている人･これからされそうな人､安全にPHP開発がしたい人向けのLTにする予定です｡