トーク

顧客情報やカード情報の流出などの問題から、サービスのセキュリティ面に対する非機能要求は年々高まりつつあります。

昨年私たちのチームで担当したアーキテクチャのリプレイスプロジェクトでは、Java製のCSMで構築されたサービスをPHP&Laravelの構成へリプレイスしました。
リプレイス前後ではサービス、機能としてのふるまいが変わらない点を重点的にテストしました。しかしふるまいに対してのテストのみでは、セキュリティ上の問題発見が困難でした。

そこで、私たちのチームではWeb脆弱性診断ツールであるVAddyを選定し、セキュリティテストを実施しました。
シナリオに沿って自動的にセキュリティテストを実施する方法や導入に関する課題、問題があるコードの発見と対処についてお話しします！

我々のチームではサービスのメトリクス監視であったり、パフォーマンス可視化にNew Relicを活用しています。
また、開発プロセスの改善や活動量からエンジニアを評価出来る環境作りのために、開発チームのパフォーマンスをNew Relicで可視化、活用しています。
本トークでは、サービスのパフォーマンス可視化だけではなく、開発チームのパフォーマンス可視化も行えるNew Relicについて、弊社の活用事例を時にはコードレベルまで掘り下げながら紹介させていただきます。
サービスや開発組織のパフォーマンスの可視化にご興味のある方々に響くトークをさせていただきます！

皆さんが使っているフレームワークは何でしょう？？
ウェブアプリケーションの開発において開発効率の向上、セキュリティの対応等のためにフレームワークを使うことが多いと思います。

私は普段はLaravelを使ってます。というか業務ではLaravelしか使ったことがありません。
他のフレームワークの様子がどうやら違うらしいという噂を聞きました。
そこで調べてみたところ、驚愕！
フレームワークによって全然違う！
調べた中で見つけた違いと魅力について、私の意見を交えて説明します。
各フレームワークの比較をして違いを理解している人は少ないかと思いますので、この発表で違いを理解しましょう！

トーク内容
各フレームワークの特徴
それぞれの設計思想、魅力
どういうプロジェクト、どういう人におすすめなのか？

対象のフレームワーク
・ Laravel
・ CakePHP
・ Yii
・ Slim

Laravelの登場は2011年、Cake PHP、Symfony、ZendFrameworkは2005年と、PHPのフレームワークには歴史があります。
しかし、私の開発しているプロダクトは2001年にリリースされており、そんな贅沢なものは使われていませんでした。

当然設計もレガシーで
・ビューロジックとビジネスロジックが分離されていない
・処理が上から下に流れるだけ
・共通関数を大量に抱えたファイルがある
など、とうてい現代の設計についていけそうにない状態でした。

そんなレガシープロダクトを、Laravelで動くようにした実装戦略を、”載せる”をキーワードにお話したいと思います。

みなさんは CodeCrafters というサイトを知っていますか？
このサイトは少し複雑なソフトウェアを作りながらプログラミングを学ぶことができるサイトです。
このサイトではRedisやDockerコマンド、SQLite などの基本的な機能を作るような練習問題があります

Redisを作る課題にチャレンジしました。そこで学んだことを話そうとおもいます。

■話すこと
・CodeCraftersってどんなサイトなのか
・CodeCrafters で Redis を作る手順について
・Redisのプロトコル(RESP)について

■ターゲット
・PHPの基本的な文法はわかるけど次に何をするか悩んでいる人
・PHP以外の言語でなにか作りたいけど作りたいものがない人

PHPで構築したシステムの監視運用について、お悩みはないでしょうか。
あるいは、「最近Obserbavilityという単語を耳にするけど、実際なに？」という方も多くいらっしゃるのではないでしょうか。

本LTでは、PHP-fpmでWordPressをAWS EC2上に構築し、
Obserbavilityの3本柱と言われるAPM, Log, MetricsがObservabilityツールの一つであるDatadogでどのように見えるかみてみたいと思います。

Obserbavilityの基礎から実際の見え方までお伝えできるよう、基本概念からお話し予定です。

PHP8.2から動的プロパティが非推奨となり将来的には禁止となることは、多くのPHPerに衝撃を与えたことでしょう。
そのような中で、例外的に動的プロパティが認められた特殊なクラスが存在します。
それが「stdClass」です。
このクラスは一体何者なのでしょう。
公式の説明を見ると「PHP には全てのクラスの親となる基底クラスの概念がないため、 このクラスは基底クラスではありません。」と記されています。

...では一体何なのか？！
現代的なコーディングにおいて動的プロパティは良くないとされ、PHPが徐々に厳格なコーディングスタイルを取り入れていく中で、なぜstdClassだけが許されているのでしょうか。
ここではstdClassの機能と用途からその正体に迫り、今後のコーディングにおいてstdClassは使って良いものなのかを説明していきます。

LaravelではRepositoryパターンは使いにくいんでしょうか。
「Repositoryパターンはデータアクセスロジックとビジネスロジックを分離し拡張性と保守性を高めた実装パターン」であると研修で理解しました。
しかしLaravel上でこの実装パターンを用いたところ、以下のような悩みに直面しました。

• 肥大化するクラスがServiceからRepositoryに移っただけではないか？
• 必要以上にファイルの数が増えてしまっているのではないか？
• 一覧表示などではパフォーマンスが劣化するのではないか？

ここではこれらの悩みに直面した新卒PHPerが奮闘し、どのようにRepositoryパターンで実装したのかを紹介していきます。
もし「もっと良い方法があるよ！」と教えてくれる先輩PHPerがいらっしゃいましたら、ぜひ教えてください。。。

列挙型がPHP8.1でリリースされて約１年が経ちました。
みなさんの現場で列挙型はうまく活用されていますか？

本トークではJava, pythonなど、他言語の列挙型の仕様と比較しながら、
PHPにおける列挙型の役割や使い方を解説します。

このトークを聴いて貴方も列挙型マスター！
列挙型を使いこなしてより楽しく、そして安全なシステム作りをしていきましょう！

今ではオープンソースソフトウェア（OSS）を使うことは当たり前になっています。このことに異論を挟む人はいないでしょう。

ところで、「OSSへのコントリビュートをするのは敷居が高い」「OSSを作るのはなかなか難しい」とよく聞きます。
確かにそれもOSSの1つの側面かもしれません。

そこで提案です。趣味としてOSSを書くのはどうでしょう？
実はOSSは趣味で書くのもアリなのです。
皆さんの中にも「プログラムが好き」「プロダクトが好き」「モノづくりが好き」という方は少なくないはずです。
そんなあなたは趣味OSSの素質ありです。

筆者は「少し実用的で小さなOSSを書くのが趣味」と公言しています。
あくまで「いち趣味の紹介コラム」としてOSS開発のはじめかたをお伝えできればと思います。

見知らぬコード、深いスタック、多様なクラスやメソッド・・・・
それらに立ち向かうのは、楽しくもあり大変でもあることですね！頭がパンクしちゃうこともしばしば！

どうしたら、少しでも効率よく・安心しながらコードリーディングを進められるでしょう。
ポイントは、「要点を掴む(=肝心でない所は脳みそからflushする)」「振り回されない(=コードを行ったり来たりしやすくする)」事だと思います。
それを実践するためのツールや技法を用意できると良いですよね。

脳内で補いきれない所は、「道具」で補って賢くやりましょう。
Xdebugのステップ実行と、ホワイトボードツール(Miro)の付箋とメモを活用することで、とっても効果的にコードの理解を進めることができます！

ある程度複雑なライブラリを例に、実際に「どうやったのか」をお見せします。

ソフトウェア開発の現場に限らず、あらゆる改善活動において「正確な現状把握」は必要不可欠です。
パフォーマンスチューニングはその代表的な例でしょう。
では、リアーキテクチャリングやリファクタリングなどの改善においては、どのように「正確な現状把握」を行えばよいのでしょうか??
本トークでは、アーキテクチャの「正確な現状把握」に役立つアーキテクチャメトリクスという概念をご紹介し、後半ではPHPのアプリケーションで使えるツールをご紹介します。

本トークでお話しすること

• アーキテクチャメトリクスの概要
• PHPのアプリケーションで使える計測ツールの紹介

DORAによる調査State of DevOpsが近年、注目を集めています。
開発組織のパフォーマンスを計測する Four Keys という指標を耳にすることが増えてきました。
この Four Keysですが、計測してみたはいいものの、実際にはどのように改善していけばよいのでしょうか??
DORAは調査の結果からFour Keysの改善効果が高いことが特定されている組織の能力をDevOps Capabilities (27のケイパビリティ)としてまとめ、報告しています。
本トークではDevOps Capabilities (27のケイパビリティ) について、1つづつピックアップし概要をまとめ、ご紹介します。

本トークで話すこと

• DevOps Capabilitiesの概要
• DevOps Capabilitiesの紹介
• 今後新しく追加されそうなCapabilitiesの紹介

PHP8がリリースされ、追加された関数の1つにあるmatch式。
多くの場合、大体比較されるのはswitch文ですが、if文も代替できることをご存知、または知っているでしょうか？

今回の発表ではmatch式の基本と応用、発展形や本題のif文代替ケースをご紹介しながらどれだけif文とさようならができるか挑戦します。

発表内容

• 改めてmatch式を理解する
• 基本形とよくある使い方
• 良くない使い方
• 応用な使い方
• 個人的にやる使い方
• （ひらめく限りの）本当に使う？とんでもmatch式

対象者

• ～中級者
• PHP8.0以上

みなさんは「共通化処理」をしたことはありますか？
したことがあるという方の大多数はきっとその「共通化処理」によって様々な課題に直面した経験があると思います。
ある時は特定処理を達成のためのif文を共通化処理に追加、ある時は汎用処理で叶えられないので継承して新しく作り直すなど……
本当に「共通化処理」というものは存在するのでしょうか？

数十年に渡る「共通化処理」という夢物語を現実世界に置き換えたときの振る舞いや実際の見え方など、そして「共通化処理」という言葉の裏に隠れる真の意味を私の強い視点からお話できればと思っています。

本トークで話すこと

• 共通化処理と呼ばれるもの
• ソフトウェアにおける共通化処理の実態
• 本当に言われてほしい表現と実現について

本トークはPHP勉強会で発表した内容をフルリプレースする予定です

2018年に「Laravel Collection の計算量を調べてみた」というタイトルで PHP勉強会で発表を行いました。
https://speakerdeck.com/hanhan1978/laravel-collectionfalseji-suan-liang-wodiao-betemita

あれから、5年。月日が流れて、Collection にはメソッドが追加され、ロジックにも変更が入りました。
というわけで、今、計算量がどうなっているのか測り直してみました。

PHP は、気軽にウェブアプリケーションを作れる言語として、初心者から熟達者まで、人気のプログラミング言語です。
一方で、せっかく作ったウェブアプリケーションも、開発を続けていくと複雑性が増して、扱いづらくなってきます。

今まさに、目の前で積み上がる負債を見て見ぬ振りをしながら、追加開発を行うのは精神的にも辛いです。
本トークでは、今の開発をキープし、難解な設計論を避け、どうやったらレガシーになりにくく、レガシーになったとしても何とかなるウェブアプリケーションが作れるかをまとめます。

本トークで話すこと

• レガシー化しにくくなる PHP ウェブアプリケーションの基本方針
• 明快で分かりやすい開発時の約束事
• 負債を生み出しにくい開発フロー・開発組織の仕組み作り

"Lean と DevOpsの科学" で有名になった Four Keys など、最近はメトリクスという言葉をよく聞くようになりました。
ソフトウェアの改善においては、まずメトリクスを計測し、KPI を定め、改善を進めるのが王道です。
ところで、PHP のウェブアプリケーション開発で使えるメトリクス計測ツールは、どれくらいあって、何の指標が測れるのでしょうか？
一通り目についた計測ツールを試してみて、その結果をまとめてみます。

本トークで話すこと

• ２０２３年３月現在の計測ツール一覧
• ソフトウェア改善で使えそうな "おすすめの計測ツール"

ウェブアプリケーションが思ったほど速度が出ないときに、"Cache"を利用することは多いかと思います。 例えば、実行時間のかかる SQL クエリの結果を "Cache" したり、複雑な計算処理の結果を "Cache" したりです。
しかし、パフォーマンスが上がるはずなのに、思ったほど効果がでないということがあります。そんなときは、"Cache" の基本に立ち返って、理詰めで考えてみることをおすすめします。

本トークで話すこと

• Cache とは何か、どのようなときに利用するのか
• Cache によって、改善されるものは何なのか
• PHP において利用可能な Cache の種類と効果
• ウェブアプリケーションのベンチマーク結果

弊社は11月に新しいサービスをリリースいたしました！
約半年間という限られた期間の中で２つ目のサービスを開発することは、試行錯誤と学びの連続でした。皆さんも新サービス開発時にAPI設計や既存サービスとの棲み分けに頭を悩ませたことはありませんか？
この登壇では新サービスリリースまでに蓄積された開発ノウハウをご紹介できればと思います。

▼お伝えしたい開発ノウハウ

・新サービスAPIの設計、構築
・既存サービスとの棲み分け
　・ログイン、メール基盤
・その他
　・feature flag運用
　・リリース前後の準備