トーク

オープンロジでは約10年もののPHPアプリケーション(Laravel)が日夜動き続けています。
コードの行数は数十万行あり、データベースのレコード数も数十億程度あります。

弊社ではアプリケーションエンジニアの採用を積極的に進めています。
巨大なコードベースかつ物流のドメイン知識は複雑怪奇なので、少しでも認知コストやレビューコストを下げ、安心して開発を進めていけるようにCI整備が肝要です。

今回は具体的に取り組んでいることについて幾つか紹介します。

開発環境構築整備 / CI整備 / Linter整備 / 静的解析整備 / UnitTest整備

リリースはサービスの価値をお客様に届けるための重要なステップです。しかし、特に長期間開発されてきたプロダクトでは、そのリリースのプロセスに課題を抱えていることが少なくありません。
サイボウズのグループウェアGaroonも、ビッグバンリリースが常態化している、機能がリリースされるまで時間がかかる、リリース後の障害の改修にも時間がかかる、複数チームが利害関係者になっているリリースプロセスが複雑で制約が多い、といった課題を抱えていました。
しかし、ここ1年でGaroon開発チームが行ったリリース改善は一定の成果を得ることができました。例えばリリース回数だけをとっても、ここ数年のリリース数が月1～2回であったのに対して、最近では月14回のリリースができています。
本セッションでは、私たちがリリース改善への共感をどのように得て、どのような改善を行い、どのような成果を得ることができたのかを紹介します。

AXELMARKでは、広告プラットフォームの開発に取り組んできました。

・大規模リクエストにどう向き合うか
・莫大なデータをどう集計して提供できるかたちにしておくか
・適した広告をどう莫大なデータから解析するか
この3点は開発において、重要なポイントになってます。

開発チームでは、9つの広告プラットフォームを開発してきました。
ADrouteというサービスについては、今もなお進化を続けています。
新規開発では、実現したいことを叶えられる技術選定を進めていますが、
運用中サービスでは、技術負債をどう解消していくか、大切にしています。

本セッションでは、
「数百億の大規模リクエストに対して技術的にどう向き合って開発しているか」及び、
「直近進めているGenerative AI をプロダクトにどう活用しているか」について紹介します。

登壇者：佐野太刀彦（CTO）、久保真哉（テックリード）

OpenStackを利用しているConoHaの課金において重要な役割を果たすシステムの一部に焦点を当てます。
このセッションでは、OpenStack Ceilometerを利用した課金の元データ収集バッチの進化と軌跡について詳しくご紹介します。
課金を計測するための元データを作成する本バッチは、バージョン3の稼働を目前に控えています。
バージョン1の引き継ぎから始まり、自身が直面した課題や感じたこと、バージョンアップに向けた改善への挑戦を共有します。
さらに、バージョン3での変更点や進化についても紹介し、ConoHaの課金元データ収集バッチの成長の軌跡をお伝えします。

■ スライド
https://speakerdeck.com/tamayama0111/typescriptdatutarafetobedotutimoshu-kerusi-le-ziyanai-typescripter-vs-phpernozhan-i

■ あらすじ
「TypeScriptだったらFEとBEどっちも書けるし、楽じゃない？」そんな一言からこの戦いは勃発した。
今PHPer vs TypeScripterの戦いが始まる!

本トークではPHPのメリット・デメリットとTSのメリット・デメリットを話します

■ 内容

• PHPでAPIを作る上での優位性
• TSでAPIを作る上での優位性
• 性能面での比較
• バグの産みやすさの比較
• ユニットテストの比較

■ 対象者

• フロントエンドもバックエンドも書いている人
• TSに興味があるPHPer

あなたのアプリケーションでは、複数のコンテキストでロジックを共有することはありますか？

例えば、ECサイトの商品ページでは、管理者が商品の内容を変更して事前にプレビューしたいケースがあります。
ここには一般ユーザーが商品ページを閲覧するコンテキストと、管理者がプレビューするコンテキストが存在します。

プレビューのロジックはどこにあるべきでしょうか。
管理者コンテキストでは、一般ユーザーのロジックを再利用すべきでしょう。完全に分離してしまうとプレビュー機能が一般ユーザー向けのロジックに追従し続けるコストが発生します。
一方で、一般ユーザーコンテキストではプレビューのロジックは不要です。プレビュー機能を改修するたびに一般ユーザー側までテストしたくありません。

複数のコンテキストでロジックを共有する場合、コンテキスト間の依存関係を適切に制御するにはどう実装すべきかを考えます。

ピープルマネジメントは「感情労働」と言われたりもしますが、その要因の1つは「色々な他人と真剣に個人対個人で向き合わなければいけないこと」だと思います。
共感し寄り添う必要がありつつ、「一緒に怒る」「一緒に焦る」という風にグラグラしていては身が持たない…という面もあります。

真面目に話を聞く！しかし適度に自身を安定させる！
その両立は、どのように可能となるのでしょうか？

リーダーシップ論を学んだり、コーチングのトレーニングを受けた事は、「自分の感情を保護する」のにも役立っていると感じます。
それらも踏まえ、自分自身がマネジメントに携わり2年ほどで、学んだ知識や実践の中で磨いてきたものを共有します。

触れたいこと

• 2種類の共感と共感的理解
• 自分と他人を区別する
• 評価と事実を切り分ける
• アサーティブなコミュニケーションを心がける
• 他人の価値観に目を向ける

皆さんはPHPStorm、Xdebugを使いこなしているでしょうか?
メソッドジャンプや、単純にテストを実行するだけで使ってないでしょうか?

このトークでは基本的なセットアップ方法から解説し開発チームが
PHPStorm + Xdebugを使って効率的にかつ、素早くデバッグを行えるTipsを紹介していきます。

・PHPコードの実行フローを追跡して、バグの原因を特定する。
・変数の値を監視し、変数の値や状態を確認する。
・ブレークポイントを設定して、特定のコード行で停止し、デバッグを進める。
・ステップ実行や式の評価を使用して、コードの動作を詳細に調査する。
・デバッグ時の便利なツールや機能を活用して、生産性を向上させる。
・Dockerを使ったリモートデバッグの設定と実行
など...

Webアプリケーションではさまざまな事情からSQLを発行したくなることがあります。
PHPでSQLを発行する際のベストプラクティスのひとつはPDOを使ってパラメータをバインドすることですが、残念ながらこの方法では可変個の要素に対して文字列組み立てを避けられません。

今回のトークでは私が社内ライブラリを再実装した「憂鬱なSQLのためのアレ、またはPDOと仲良くして枕を高くしてねむる」で紹介したライブラリを2022年にどのようなコンセプトで再設計したのかを紹介します。

「チームでふりかえりをしている」という組織は多いと思います。
どんなふりかえりをしていますか？あるいは、何の為に行っていますか？

実際には、「出来事や結果を共有する」「その再発防止や改善について話し合う」ものになっている事が多いかも知れません

良いふりかえりは、「上手いやり方を学ぶ場」を超えて「チームが学び方自体をアップグレードして行く場」に成り得るはずです！
チーム自体の進化を促したり実感できるふりかえり、できていますか？
そうでないのであれば、何ができていて・何が足りていないのでしょうか。

「学習する組織」のコンセプトをヒントにして、ふりかえりについて改めて考えていきます

はなすこと

• ふりかえりの基本
• なぜ学習が大事なのか
• 個々人の意見出しからチームの相互作用へ

関連するキーワード

• 学習する組織
• 体験学習・わかちあい
• 自律的な組織づくり

アジャイルサムライの中では「概算見積もりは当てずっぽう」と書かれ、相対見積もりを推奨されています。
スクラムではストーリーポイントという名前を使って単位の意味合いを曖昧にすることで時間やお金に対する「約束」という概念から遠ざけています。

しかし、プロダクト開発をするうえではプロダクトロードマップがあり、それを達成することで事業成功を牽引する開発チームがあります。
プロダクトロードマップを作成するにも概算見積もりはあったほうが立てやすいですが、それが「約束」となって開発チームへの「呪い」ともなるケースもあります。
そんなPdMとエンジニアの狭間で、見積もりに対する考え方を言語化しチームに伝搬していこうとする話です。

REPL（Read-Eval-Print Loop）はコードのデバッグ、小さなスクリプトの実行、簡単な計算などを行うのに便利な対話式環境です。
代表的なREPL環境にはRubyのirbや、PHPのbobthecow/psysh があります。
使ってみて便利な一方でどのような仕組みで動いているのでしょうか?

このセッションではREPLの解説から実際、Read（読み込み、）Eval（評価）、Print（出力）、Loop（ループ）
それぞれの処理をPHPで書きながらどのような仕組みで動いているのかを解説して、紹介を行います。

みなさんライブラリを公開していますか？ PHPのサポートバージョンをどうやって決めていますか？

原則論で考えればEOLを迎えてサポート終了したバージョンや、極論をいえば自分が使っているPHPのバージョン以外はサポート継続する義理はないわけですが、技術者としては可能な限り古いPHPでも使えるように互換性を保ち続けたいというのは人情ではあります。

このトークでは個人的な興味でメンテナンスを継続しているPHPライブラリでいかにして後半なPHPバージョンをサポートしているか、そして開発体験を落とさずに古いバージョンへのサポートを維持するために考えられるテクニックについて紹介いたします。

本LTでは、入社半年を迎えるエンジニアの私が、社内外で主体的に参加・主催したカンファレンス・勉強会でのエピソードや取り組み、そこから得た学びを紹介します。そして、少しだけ未来の自分に伝えたいメッセージをお話します。
エンジニアを取り巻く環境はここ数年で目まぐるしく変化しています。リモートワークの増加によってエンジニアリングのスタイルやコミュニケーション方法も大きく変わりました。
人と技術、人と人の出会いの場となるオフラインカンファレンスや勉強会のニーズの高まりを改めて感じる機会が増えています。
本LTは、PHPに直接関連する内容ではありません。私が過去に参加した様々なカンファレンスや勉強会から得た学びについて、多くの方々に共感していただけるような体験談をお届けしたいと思います。
そして、今を生きるエンジニアとして、未来の自分に送るタイムカプセルになるようなLTができればと思います。

「プログラミング、上手くなりたいです！」
しばしば聞かれる質問です。
「まずはエラーを気にしましょう！」
最近はこう答えるようにしています。

プログラミング言語は、(数学や理学の世界と比べて)人工的であり恣意的な創造物です。
エラーが出ると怖い・面倒臭いと思われるかも知れませんが、
温室に氷を放置すれば溶けていくのに比べて、プログラミングのエラーは「誰かがわざとそうしている」に過ぎません。

プログラマにとって、なぜエラーが重要なのでしょう？
あるいは、PHPを作る人は、何をエラーとして何を許容してきたのでしょうか？

このトークでは、

• フィードバックシステムとしてエラーの機構を捉えた時に、何の利益を提供しているのか
• エラーの変化から、昨今のPHPの進化を読み解いてみる

事を試みます。
それによって、エラーと仲良くなって、「まともなコードを書ける」人が増えることを目指します。

アスペクト指向プログラミング（AOP）は、アプリケーションのコードベース全体に横断的に影響を与える部分（Cross-cutting concern）を効果的に管理するためのプログラミングパラダイムで、
オブジェクト指向プログラミングには無い新たな視点を提供します。

本トークでは、まずAOPの基本概念や利点について確認します。
その後、PHPで実装されたAOPライブラリを紹介し、どのように実装されているのかをライブラリによる違いや共通点に着目して深掘りします。
最後に、AOPを導入・活用するにあたってのポイントなどを紹介します。

本トークを通じて、AOPの基本概念を知り、PHPでどのように実現されているかを知ることができます。

「テストがないコードはレガシーコードだ！」
Webアプリ開発においてPHPUnitなどでテストが書かれることは一般的になりました。

ですが、テスト完走までにかかる時間は適切でしょうか？
テストにかかる時間は生産性に直接的な影響を及ぼす重要な要素です。早ければ早いほど良い。
本トークでは、PHPUnitで書かれているテストを高速化するテクニックについてお話します。

対象観客

• テストが遅いと感じる開発者
• チームの生産性を上げたいと考えている人

お話すること

• phpunit-speedtrapプラグインを使って遅いテストを検出する
• Laravelで良く使われがちなDatabaseMigrations Traitは出来るだけ使わないほうがいい話
• "make -j" やparatestを使った並列化

「テストがないコードはレガシーコードだ！」
Webアプリ開発においてPHPUnitなどでテストが書かれることは一般的になりました。

ですが、テスト完走までにかかる時間は適切でしょうか？
テストにかかる時間は生産性に直接的な影響を及ぼす重要な要素です。早ければ早いほど良い。
本トークでは、PHPUnitで書かれているテストを高速化するテクニックについてお話します。

対象観客

• テストが遅いと感じる開発者
• チームの生産性を上げたいと考えている人

お話すること

• 目指すべきテスト時間
• phpunit-speedtrapプラグインを使って遅いテストを検出する
• Laravelで良く使われがちなDatabaseMigrations Traitは出来るだけ使わないほうがいい話
• "make -j" やparatestを使った並列化

話者は好んでOSSのBrefを利用したサーバーレスのシステムを構築しています

その中で不自由なくLaravelを利用しているのですが、
AWS Lambdaに大きなフレームワークを組み込む事は１つのアンチパターンだと認識しています

しかし自分の体験を元に考えると、本当にアンチパターンなのかを疑問に感じており、
その疑問を解消するために、必要な機能のみ切り出したフレームワークを自作することにしました

フレームワーク実装について学びながら
本当にAWS Lambdaに大きなフレームワークを利用するのが
アンチパターンなのかLaravelと比較しながら検証します

アンチパターンを正面から踏み込むことで、新しい議論の場を作れればと思います

• 想定する聴講者
  • サーバーレスに興味がある方
  • フレームワークの自作に興味がある人
  • Brefが好きな人、気になる人

セキュアなアプリケーションを実装することはとても大事なことですよね。
しかし、開発者だけで様々なセキュリティ対策を施すのは限界があります。

そこで本セッションでは、GitHubが提供する機能を活用することで「セキュリティ対策の仕組み」を構成する方法について解説します。

また、GitHub Actions＋クラウドサービスで実装可能なDevSecOpsについても解説を行う予定です。