トーク

アプリケーションのパフォーマンス改善を行う場合、適当に手を動かしてもうまくいかないことが多いと思います。

少しでもよいカイゼンを行うためには「事実」を把握するために「計測」するというアクションが大事です。

ツールを使ってコードのメトリクスの取得するのも1例です。
コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などコードに対する「事実」を把握することができます。

把握できた色々な「事実」を元に、どこがアプリケーションの改善点なのか…？何がアプリケーションにとって最適なのか…？？プロダクトにもっとも寄与するためには…？？？を考え「判断」し、「行動」に繋げていきたい。

このトークではどのように考えてカイゼンのための行動をとっているのか？をお伝えしたいと思っています。

Laravelには便利な機能がたくさんあり、Eloquent、Facede、サービスコンテナ、認証、ミドルウェア、Blade、artisanコマンドなどの機能を活用することで、スピード感のある開発ができることは間違いありません。

ただ、それらに依存しすぎることによる弊害も少なくないでしょう。ビジネスの変化への対応による作り直し、各機能のバージョンアップの際に思わぬ量のコード修正になってしまうことがあります。

そんなことを想定し、Laravelのコードからドメインのコードが独立するよう、主にInterfaceを利用してドメインロジック（＝わたしたちのコード）を切り出すことを心がけています。

まずLaravelで素早く開発するための例を紹介し、どのようにしてLaravelのコードとドメインのコードの距離を保っているか、どんなメリットがあるのかを事例を交えて紹介させていただきます！

PHPドキュメンテーション
「password_hash() は、 アルゴリズムやコスト、ソルトといった情報もハッシュに含めて返すことに注意しましょう。 」
ぼく
「え、ソルトも同じところにあったら意味ないんじゃ？」

このセッションでは、そんな疑問に答えるべく、password_hash関数について掘り下げて解説します。
そもそもパスワードをハッシュ化する目的や、パスワードにまつわる攻撃手段とその対応を見ていきましょう。

話すこと
・ハッシュ化とは何か
・なぜパスワードはハッシュ化するのが良いのか
・ソルトは何を解決するか
・ブルートフォース攻撃やタイミング攻撃への対応

みなさんは Serverless アーキテクチャをお使いでしょうか。
PHP では、 Bref と呼ばれるサードパーティ製のランタイムを用いることで Serverless 、正確に言えば Function as a service 環境上でアプリケーションを動かすことが可能です。
しかしながら、このアーキテクチャは専ら CDN を組み合わせ、公開されたインターネット環境から アクセスしてくることを基本としており、それ以外のアクセスが制限されている環境 = 閉域網下において、このアーキテクチャが採用されたケースは、あまり見ることができません。
このセッションでは、 DirectConnect を用いた閉域網下の環境にて、 Serverless アーキテクチャを採用した Laravel アプリを実装し得られた知見についてお話ししたいと思います。

私の所属する株式会社リンケージは、CTOの曽根壮大をはじめPHPカンファレンスやコミュニティに関わりの深いエンジニア社員・業務委託が多く働いています。

私は、エンジニア社員に誘われたのをきっかけに、今年の6月に開催されたPHPカンファレンス福岡2023に参加してみたのですが、あまりの楽しさと面白さに感動し、その後、9月の沖縄（オンライン）、10月の東京（オフライン）と3連続でPHPカンファレンスに参加しています。

私自身はPHPerでも、もはやエンジニアですらなく、事業開発出身のプロダクトマネージャーです。

傍から見ると、講演内容は分からず、参加しているエンジニアの方々とも話せないのではないか？と思われる方もいるかもしれません。
私がなぜPHPカンファレンスに参加し続けているのか、その魅力を「非PHPer」「非エンジニア」という私にしかない視点から熱くお伝えします！

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

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

このセッションでは、インフラ知識の無い初心者でも分かるように、柔軟な構成で効率的にPHPサーバーを自動構築する手法についてお伝えします。

主な対象

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

一言で「PHPでのプログラミングを勉強する」と言っても、多くの要素が含まれます

1. プログラミングの思考を知る
   • 変数、手続き、条件分岐、etc…
2. PHPの文法や機能を知る
   • キーワード、関数、etc…
3. ソフトウェア開発に必要な態度や技能を考える
   • 読み易さ、エラー、etc…
4. 良いソフトウェアについて考える
   • 抽象、テスト、etc…
5. 学び方について知る
   • 先輩に頼る、情報収集、コミュニティ、etc…

等々。

初心者・入門者から初級者への上昇には、
例えば「指示の内容(単語や言いたい事)が理解でき、実施できる」は1つの目安です
どう歩めば良いでしょうか？

5つの要素について、オススメ書籍の紹介を交えながらお話します

対象

• プログラミングやPHPを勉強し始めた人
• 新人教育を担う先輩・マネージャー

テスト駆動開発（TDD）を使えば、安心感を持ってコードを変更できるようになったり、スモールステップで開発できるようになったりするという恩恵を得られます。
このセッションでは、ターミナル上で動作するリバーシを題材にしてTDDの基本を解説します。

セッションの内容 :

• TDDの説明
  • TDDサイクルの説明（Red-Green-Refactor）
  • TDDのメリット・デメリット
• PHPでテスト駆動開発を始めるための下準備
  • PHPUnitのインストールと設定
  • Gitの設定
• 実装の流れ
  • ざっくり設計する
  • Todoリストに起こす
  • テストを書きながら一つひとつ実装する

主な対象者 :

• テスト駆動開発に興味がある方
• テスト駆動開発本を写経してみたが、次に何を作れば良いかわからない方

仕事(公私に関わらず！)をする上で、計画って大事ですよね！
計画があることによって、他人に信頼をもらえたり、あるいは危機感を共有しやすくなるのです。

が、計画ってムチャクチャ難しくないですか？
難しい…つまり、成功しにくいということです。
そして、計画を立てるコストもタダではありません。
破られる・当たらない計画に、時間や人件費を掛けるのが、良いことですか・・・？

私は、「計画の精密化に時間を掛ける位なら、最初は”宇宙と交信して声を聞きました”で数字を出していいよ」と言いました。
そう言われた相手は、引いていましたが。

計画は立てるのが大事。そのために話すことが大事。それを使ってコミュニケーションを取ることが全て。
それらの意義に比べれば、「計画行為の成果物としての計画そのもの」は、副産物みたいなものだ！！とさえ思います。
信じるためでなく、疑うために計画行為を。

そんなLTです

PHPのコーディングスタイルの治安を守るツールには、強力なプレイヤーが複数居ます。

• 老舗どころ！ squizlabs/php_codesniffer
• 強力な統治！ friendsofphp/php-cs-fixer
• 新進気鋭！ symplify/easy-coding-standard

どれを選びますか？
「利用しているFWと親和性が高いもの」で選ぶのも良いですし、
「標準やコミュニティでどんなルールセットが存在するか」もポイントになります。

「似たツール、どれを好む？」が、新しい自転車置き場の屋根の色になってしまっては、本末転倒です。

機能的な比較は1つの基準になりそうです。

• ルールセットや設定ファイルの作り方
• 独自の(個別)ルールの実現方法
  に注目してみては如何でしょうか？

このトークで「設定の仕方」「ルールの作り方」で比較し、それぞれの思想も紐解きます！

EMを始め、マネージャーやリーダーには「人を動かす」という場面が多くあります。
「目標を定義する」「組織での解決をデザインする」「仕事を割り当てる」、こんな流れです。

他人の参加を前提にした物事は、「その人が動いてくれなかったら」で達成が危機に晒されたりもします。
マネジメントには、こうしたリスクを織り込んで、安全にゴールまで辿り着く事が求められます。
他方で、「大きな仕事を与える」「自由にやらせる」ことの効能が、強くしなやかな組織を育む上で重要だと見做されています。

私が両者の狭間で足掻きながら見えてきたのは、「信頼するけど期待しない」という感覚です。
このトークでは、自身の経験を通じて掴んだポイントを共有します。

トピック

• 私はなぜ「人の才能に頼る」ことが好きなのか
• 「信じる」と「期待する」の違い、比較
• 現場において、どのように実践していくか？、その言動

世の中に入門書や入門者向けの記事は溢れています。
上級者向けの書籍や記事も増えています。
入門書を終えた後、次のステップに進むために何を学ぼうか悩んでいるビギナーの方は多いのでは無いでしょうか？
PHPを使って業務で開発を行っていくうえで、次のステップとして学ぶと良いことを具体的なケーススタディを交えてお話ししていきます。

◆対象者
・入門書をやり終えた程度のPHP初心者
・簡単なWEBアプリケーションが作れるようになったPHP初中級者

◆話すこと
・バグを生み出しづらい書き方
・コーディング規約
・チーム開発において読みやすい書き方
・コメントの入れ方
・セキュリティを意識した書き方
・エラーの見方

privateメソッドのテストを書くか書かないか問題はよく話題にあがるかと思います。
実は、私もかつてはprivateメソッドのテストをたくさん書いていた時代がありましたが、今はprivateメソッドのテストは書かずにテストを書いています。
自分の思考の整理をするのに繋がった「単体テストの考え方/使い方」という本の内容からも引用しつつ、
実体験をベースに「なぜprivateメソッドのテストを書かないのか」というところをお話します！

トークで話す内容

• かつて私が書いていたprivateメソッドのテスト(と、その理由)
• なぜそれが良くなかったか？「偽陽性」「偽陰性」の視点から考える
• どのようにテストを書くべきだったか？
• privateメソッドのテストは書かない方がいいのか？(※経験に基づいた持論)

オブジェクト指向プログラミングにおいて重要な概念となる「SOLID原則」 。
本セッションでは、自分が違反して書いてしまったコードを例に、SOLID原則を紹介していきます。

• どのSOLID原則に違反しているか
• 違反がもたらす具体的な問題
• 正しい実装

多くの書籍でSOLID原則に関する具体例が示されていますが、このセッションでは「実際の失敗例」を通じてSOLID原則を理解していただこうと考えています。
自分がミスってしまった実装例を、時間の許す限り赤裸々に公開します！！

みなさん、commitで物語は書いていますでしょうか？私は書いています。

commitとは「読み手を意識して書くもの」、すなわち物語なのです。
commitは歴史に残る重要な資産と考えている私のcommitの積み方を聞いてください！
共感したら始めてみて欲しいです！

私がcommitを積む上で気にしていること

• 読者にとって不要な「物語（=commit）」は積まない
• 「起承転結」を意識する
• 「文脈」を的確に伝える

CI(テスト実行)が遅いという問題はありませんか？🤔
そしていろんな理由からスマートなパラレル実行がしにくいかったりしません？🤔🤔
わたしの社内でも同じ問題がありました。

そんな現状に困っている方向けに本セッションでは
PHPUnitの機能とちょっとした工夫でCI実行時間を短縮する方法をご紹介します！
この方法は以下のことに触れていきます！

• PHPUnit
• Github Actions
• ボトルネックなテスト発見手順

みなさんとみなさんの開発メンバーの生産性向上のお役に立てると幸いです！！

TechTrainというバックエンドがLaravelのプロダクトで5年ほど運用してきました。コードベースも大きくなり、リファクタも積み重ねなくていく必要が出てくるくらいにはなっています。
度々部分的に記事でCI/CDについて紹介されていることはありますが、本番環境で何を全体的に運用するのか？といった紹介がないので、導入し、必要なところを改善するのに少し苦労しました。
このトークでは、Laravelの運用にあたり、何をCI/CDで導入し、どういうポイントを抑えると、楽にできるのか？について詳しくお話しします。

OpenTelemetryといえば、最近インフラ界隈で話題のワードですよね。
ただOpenTelemetryにはたくさんの専門の用語が登場し、さらにOpenTelemetryの公式のドキュメントをそのまま実行しただけで導入ができず、つまづきポイントがとても多くなっています。
TechTrainにおいて実際に導入しました。このトークでは次のようなことについてお話しします。

1. 事前にどういうことを検討したのか？
2. 導入にあたって、つまづきやすいポイントはなんだったのか？
3. 本番運用を始めてみてどうだったのか？

PHPは20年を超える歴史を持つ言語で、php.netでは度々「歴史的な理由」という単語を見かけます。
このトークでは、php.netの標準関数における説明において「歴史的な理由」がなぜ生まれたのかを追い、PHPの歴史とともにその理由について深掘ります。

どのプログラミング言語の初心者にもお伝えしたい知見「テストを書こう」のPHP版です。
これは私が考える「良いコードを書くための心得」です。

初心者時代の私は目指してはいても変更しやすい実装ができませんでした。
実はこれは達人ケント・ベックも同じようで、それを知って以降、少しずつ実装を改善する道を選びました。
テストコードがあると、変更前後で振る舞いが変わっていないかを何度でもすぐに確認できます

こんな方に向けて話します

• PHPの文法を理解されている（特にクラスが書ける）
• テストコードは書いたことがなくて全然OK
• 変更するたびに実は祈っている（こっそりどうぞ）

こんなことを話します

• テストコードが書けるメリット
• PHPUnitでテストの書き方（FizzBuzzを例に）
• テスト駆動開発（小さいサイクルをデモします）
• 発展：モックを使う