トーク

PHPでAPIサーバーを作っていますか？
APIの仕様書は書いていますか？何を書いていますか？
たとえばJSONデータをPOSTするときに、JSONデータの仕様書も書いていますか？
APIサーバーをPHPで作り、フロントエンドをTypeScriptで作っていれば型を導入できますが、APIで送受信するJSONデータについて共通した型定義は導入できません(JSONスキーマを使っていれば別ですが)。
Protocol Buffersを使うことで、APIで送受信するデータに型を導入できるようになります。
このセッションでは、Protocol Buffersの紹介から、実際にPHPやTypeScriptでどのように使うのか、解説します。
※こちらはサンプルコード解説なしの短縮版となります

PHPでAPIサーバーを作っていますか？
APIの仕様書は書いていますか？何を書いていますか？
たとえばJSONデータをPOSTするときに、JSONデータの仕様書も書いていますか？
APIサーバーをPHPで作り、フロントエンドをTypeScriptで作っていれば型を導入できますが、APIで送受信するJSONデータについて共通した型定義は導入できません(JSONスキーマを使っていれば別ですが)。
Protocol Buffersを使うことで、APIで送受信するデータに型を導入できるようになります。
このセッションでは、Protocol Buffersの紹介から、実際にPHPやTypeScriptでどのように使うのか、サンプルコードを交えて解説します。

みなさんのアプリケーションはたくさんのライブラリの力を借りて実装されていると思います。
しかし、安易にライブラリに依存した実装をすると、ライブラリをアップデートしようとしても変更箇所が多すぎてなかなかアップデートできないなんてことがままあります。
では一体どうですればいいのでしょうか？ライブラリを使わずに実装すればいいのでしょうか？

いいえ、そんなことはありません。
このトークでは、ライブラリへの依存を極力抑えたままライブラリを活用する方法について解説します。

現職にて、PHP アプリケーションを Go のアプリケーションに移行するタスクがふってきました。
現在のクライアントとのインターフェースを守りつつ、アーキテクチャなどを検討しました。
本セッションでは、そのときの検討過程や、実践した内容を共有したいと思います。
また、大部分は言語関係ない話になりますが、 PHP での実装と Go での実装に差が出たところにも触れたいと思います。

――勉強会を主催したものの、参加者が集まらない。
勉強会を主催する側として、このような状態はできるだけ避けたいものです。
地方で勉強会を開催する場合、首都圏とのエンジニア人口比率の違いもあり、メジャーなテーマでなければ人が集まらないことも…。
マイナーなテーマであっても、より多くの人にコンテンツを見て頂きたい…！
「日本中から参加者を集めれば良いのでは？」
運営チーム内でそんな声が上がりました。
あるエリアだけでは人が集まらなくとも、募集するエリアを広げれば、テーマに興味関心を持ってくれる人は増えるはず！
…とはいえ、遠方の技術系イベント・勉強会に参加するのって、交通費やら宿泊費やら、何かと大変ですよね？
「そうだ、リモートで多拠点から参加できるようにすればいいじゃないか」

リモート開催に関する物理的なノウハウなどは、さほど多く世に出回っていないようですので、
自社（東京・大阪の２拠点）で行っている、リモート勉強会で使用している機器・環境、進行ノウハウについて
ご紹介させて頂き、日本中・世界中のエンジニアの距離を縮めることに一役買わせて頂きたいと思います。

去年の5月から「Laravel.shibuya」というIRT(Interactive Round Table)メインにした勉強会を開催するようになりました。
IRTをメインとした勉強会の事例があまり無く、不安もありましたが、第1回では応募開始からすぐに満員となり好調なスタートを切る事ができました。
しかし、いざ開催してみるとIRTならではの課題が見つかります。

・IRTをメインにしてるにも関わらず上手くディスカッションが回らない
・経験の差でどうしても上級者の方が喋ってしまい、初心者の方は一方的に聞き手に回ってしまう
・隣のテーブルが盛り上がると話題が全然聞き取れない。
・IRTのトークテーマが事前に集まらない。

これらの課題について運営メンバーで取り組んだ改善方法についてご紹介します!

弊社のあるチームでは、CI で実行される PHPUnit のカバレッジ取得が 6 時間もかかっていました。
試行錯誤の結果、これを 18 分まで高速化することができました。

PHPUnit は、カバレッジ取得を有効にすると、有効にしていないときと比較して大幅に遅くなりがちです。
遅くなる理由の一つは、xdebug によるカバレッジ情報の取得が遅いことです。
また、別の理由として、グローバルな状態に依存したコードをテストするため、
PHPUnit の process isolation オプションを有効にして毎回プロセス起動を行ってしまうことがあります。

これを解決するために、以下の改善策を行いました。

・xdebug の代わりに pcov を使用する
・並列実行する
・process isolation オプションを無効にし、backup globals や backup static attributes を有効にする

このときの調査や改善活動で得た知見についてお話いたします。

あまり使われないPHPのマジックメソッドですが、使い方次第ではとても便利に使うことができます。
書籍にもあまり載っていないPHPの数少ない黒魔術の使い方をお話しします。

FaaSと言えばAWS Lambda?
いいえ、他にも様々なFaaSはあります。

今回はAzure Functionsを利用してみます。
みんなでFaaSの使い方を覚えましょう！

■お話する内容

• Azure Functionsの使い方
• Tips

■お話しない内容

• 細かな仕様

Serverless は僕達をサーバー管理から開放してくれます。

未来の投資として非常に有益だと考えているのですが、構築するには様々な知識が必要になります。

今回はMicrosoft Azureを利用した Full Serverless Applicationを開発する為のTipsをご紹介しようと思います。

このトークによりみなさんがサーバー管理から解放される一歩を踏み出せればと考えています。

■お話する内容

• アーキテクチャ説明
• 開発手法
• テスト

■お話しない内容

• 認証
• CI/CD

■関連技術

• Azure Functions
• Azure Storage
• Azure Cosmos DB

Serverless は僕達をサーバー管理から開放してくれます。

未来の投資として非常に有益だと考えているのですが、構築するには様々な知識が必要になります。

今回はMicrosoft Azureを利用した Full Serverless Applicationを構築する為の方法をご紹介しようと思います。

このトークによりみなさんがサーバー管理から解放される一歩を踏み出せればと考えています。

■お話する内容

• アーキテクチャ説明
• 開発手法
• 認証
• テスト
• CI/CD

■関連技術

• Azure Functions
• Azure Storage
• Azure Cosmos DB
• Azure Active Directory
• Azure Resource Manager

皆さんの職場では継続的なライブラリのアップデートができているでしょうか？
弊社では1年以上前からcomposer updateを自動化し、毎週PRが自動で作成される環境を作ることで、マージするだけで簡単にバージョンアップできるような仕組みを取り入れました。しかし、仕組みは作るだけで終わりではなく日々の運用や改善がないとうまく回りません。

本トークでは、毎週composer updateをする試みを実際に1年以上継続した中でうまくいったこと、逆にうまくいかなかったこと、そしてどうやって改善していったかをお話します。

関連リンク

• PHPフレームワークのバージョンアップを支える技術 - コネヒト開発者ブログ
  • https://tech.connehito.com/entry/2019/05/14/121215
• Composerのupdateを自動化した話 / phpstudy-128-composer-update-request - Speaker Deck
  • https://speakerdeck.com/o0h/phpstudy-128-composer-update-request

プロダクト開発に置いて、様々なデータを集め、取得し、分析、活用していくのが当たり前になってきました。
しかし専属の分析担当/チームがある会社もまだ多くはないかもしれません。

そういった場合に取得と分析を誰がどうやっていくのかがいいのでしょうか。

例えば下記のようなケースもあるかと思います。

• エンジニアが分析担当を兼任し、ビジネスサイドは関与しない
• ビジネスサイドから欲しいデータの抽出をエンジニアに依頼、ビジネスサイドが分析していく

私達はスピードと柔軟性のためにビジネスサイドもエンジニアも一緒にやっていくことを選びました。
それを実現するにはビジネスサイドもSQLを活用できないといけません。

ビジネスサイドとエンジニアが協力をして実際にどういうことを行ったか、
ビジネスメンバーはどういうことからはじめて、どれくらいのことができるようになったのか、エンジニアとどういう分担をしているのか、
そしてそれらを行っていく中でうまくいった点や改善点についてPHPerのエンジニアが話します。

※ 具体例としてDBはBigQuery,データはFirebaseで収集したアプリのイベントを使います。

想定する聴講者

• 経験や職種関係なくSQLを活用して、データ抽出を行いたい、ダッシュボードを作りたい方
• SQLの活用を他のメンバーにも広めたいエンジニア

話さないこと

• PHP
• 分析の詳細
• SQLの詳細の文法

プロダクト開発に置いて、様々なデータを集め、取得し、分析、活用していくのが当たり前になってきました。
しかし専属の分析担当/チームがある会社もまだ多くはないかもしれません。

そういった場合に取得と分析を誰がどうやっていくのかがいいのでしょうか。

例えば下記のようなケースもあるかと思います。

• エンジニアが分析担当を兼任し、ビジネスサイドは関与しない
• ビジネスサイドから欲しいデータの抽出をエンジニアに依頼、ビジネスサイドが分析していく

私達はスピードと柔軟性のためにビジネスサイドもエンジニアも一緒にやっていくことを選びました。
それを実現するにはビジネスサイドもSQLを活用できないといけません。

ビジネスサイドとエンジニアが協力をして実際にどういうことを行ったか、
ビジネスメンバーはどういうことからはじめて、どれくらいのことができるようになったのか、エンジニアとどういう分担をしているのか、
そしてそれらを行っていく中でうまくいった点や改善点についてPHPerのエンジニアが話します。

※ 具体例としてDBはBigQuery,データはFirebaseで収集したアプリのイベントを使います。

想定する聴講者

• 経験や職種関係なくSQLを活用して、データ抽出を行いたい、ダッシュボードを作りたい方
• SQLの活用を他のメンバーにも広めたいエンジニア

話さないこと

• PHP
• 分析の詳細
• SQLの詳細の文法

2019年11月、GitHub Universe 2019で「GitHub Actions」がついに正式版になったことが発表されました。
これまではベータ版として公開されており、v1, v2と大きな仕様変更を経て正式版公開となったわけですが、興味はあるもののしっかりとキャッチアップできている人はまだまだ多くないのではないでしょうか？

本トークではGithub Actionsを1から解説し、実際にこれまでCircleCIやTravisCIで行っていたPHPアプリケーションのCI/CDを、Github Actionsを利用して実現できないかを検証します。
Dockerコンテナを活用しつつ、PHPUnitによるテストや、phpcs・phpstanといったQAツールを実行する具体例として参考となるものにできればと思います。

PHP Code Snifferはコミュニティで広く支持を得て、活用されています。その為の仕組みや資産、例えばCI上での活用tipsに始まり、IDEとの連携・支援も拡がりました。これらの状況は、導入を考える人たちを強く励ますものです。
多くの場合は、「そのまますぐ使える」という土台が整っているとも言えます。フレームワークが提供しているrulesetを用いたり、PSR-12を適用するのは合理的な判断です。

しかしながら、このツールはあくまで「開発者を支援する」ものであり、「開発者を支配する」ものではありません。世間の標準に乗っかるだけでなく、チームやプロダクトの事情に応じて、本当に欲しいルールを手に入れるべきです。

そう考えた際に、独自のルールを作成できると夢が広がりませんか？
例えば、「PHP Code Sniffer」「PHP_CodeSniffer」「PHP CodeSniffer」正しいのはどれでしょうか？少なくとも言えるのは、チームでの正解はチームが決めれば良いのです。

ルールを自作する力を得て、より踏み込んだ活用の可能性を見つけませんか。

CakePHPが2015年以来のメジャーバージョンアップを行い、その番号は「4」を刻みました。
まだ「CakePHPといえば2.x時代のイメージ」という人も多いと思います。しかし、3.x台では、現代的な開発現場の要求に十分に応えられるフレームワークへと進化を遂げています。
そして4.xは「PHP7.1すらEOLを迎えた今」の時代に立脚したフレームワークです。

2.xとの比較の視点も簡単に織り交ぜつつ、「どんな魅力を持つのか」「4.xの特徴や推しポイントは」といった紹介をします。

先日、18年間運用されているシステムで大量のユニットテストを書きました。その際大量のモックを利用し、必死にコードの動作を制御するという経験をしました。
そこで得られた知見を整理すると、ぼんやりとクリーンアーキテクチャにつながる出口が見えてきました。
なぜモックを書かなければならなかったか、大量生産したモックはいったい何を意味するのか。
モックを使うことでテストを通すだけでなく、モックを利用して設計を改善する方法があるということをご紹介します。

レガシーシステムの開発中に訪れるPHPのEOL。バージョンアップ後は全機能テストが待っています。
既存のテスト仕様書では重要機能を網羅していない、書かれている単体テストは重要機能をテストしていない・・・
このような状況でユニットテストを書くためには、問題の分割と、テストで担保したいこと(目的)の設定が重要です。
18年にわたって運用されているシステムに対して、PHPUnitと、PHPの挙動を操作するuopzという拡張を利用してテストをどのように行ったのかをご紹介します。

いわゆるレガシーシステムを運用していくにあたって、ユニットテストをどう書いていくべきでしょうか。
長大な関数、引き回されるグローバル変数、オブジェクト指向へのチャレンジの痕跡・・・このようなコードのユニットテストを単純に書くのは至難の業です。
先日、18年にわたって運用されているシステムで重要機能のカバレッジを100%にするというチャレンジを行いました。
その際に、ユニットテストとモックを駆使して問題を分割していくというアプローチを取り、一定の成果を得ることに成功しました。
今回はこのチャレンジで得た知見から、テスト手法の紹介と、今回取ったアプローチを突き詰めた先の展望についてお話します。