トーク

私達は昨年から、10数年続いたサービスの配信基盤とAPIをリプレイスしています。
現在Adobe Media ServerとFlashで構築しているシステムを、WebRTCで再構築しています。

APIはフレームワークを使わず実装されていましたが、PHP7とLaravelの構成に作り直しています。
このセッションでは、自分たちの昨年からの歩みとして、現在のアーキテクチャになった経緯と苦労を話して行きたいと思います。
今後リプレイスする方の参考になれば幸いです。

話そうと思う技術
・WebRTC
・Laravel
・AWS

PHPは多くのテキストエディタでサポートされている言語ですが、どこまでPHPに特化して編集をサポートしているかはエディタによってさまざまです。

PHP ModeはEmacs上に構築されたPHPの開発環境であり、私はPHP Modeの現行メンテナを務めています。

本トークではテキストエディタやPhpStormを含めたIDE(統合開発環境)によるPHPサポートの現状と、エディタによる開発支援機能の理想について、PhpStormやEmacs PHP Modeの実例を挙げて紹介します。

Emacsの言語編集モード(メジャーモード)は伝統的に構文要素を色付けするだけでなく、自動インデントなど比較的高度な機能が要求されます。

技術的なおもしろさとして、テキストエディタは完成されたプログラムではなく、人間がキーボードで入力する途中の不完全な状態のソースコードを対象とする必要があり、通常の言語処理系とは多少違った独特の考慮事項についても紹介します。

コンテナコンテナしている時代ですが、それでもDockerやk8sなどを使わないサーバー構成はなくなることはないでしょう。

このトークでは、AnsibleでPHP環境を構築するユースケースを紹介します。
Pythonなんて必要ないので、是非気軽に構成管理を持ち帰ってください。

私は、何件かPHP5からPHP7移行をしてきました。
実はPHP7に移行して動かなくなるのは、実は稀なケースであり、すんなりと動きます。
PHP7は怖くないです、移行する価値は絶対にある、そんな話をしても、移行していない人は乗り気じゃない。

移行しない理由にメリットの少なさというか、早さ以外のメリットが出てこないのです！
「PHP7早くなったんでしょ？うちでは動作スピードを求められてないからねー」
「PHP7は早くなったけど、色々と無くなった（関数）んでしょ？」
「PHP7の早さだけで移行予算は組めないんだよね」

そこで早さ以外のメリットを語ってみたいと思います。

だいぶ流行になってきているGraphQL、これをフロントエンドとのインターフェースに利用した、
バックエンドGraphQLサーバーの構築を機会あって経験しました。

以下のような事項に関して、この経験で得た教訓をご紹介できればと思います。

• スキーマ駆動開発のメリット・デメリット
• リポジトリパターン実装におけるスキーマから実DBへの処理クラス切り換えタイミング
• lighthouse-php の「利用のしどころ」
• このようなLaravelとの連携ツールがあってほしかった
• 通信・環境面での苦労

可能な限り、バックエンド開発者としての自分のみではなく、フロントエンド開発者・インフラ運用者、等の
複数の立場からの見解を盛り込めればと思っています。

東京都にある「葛󠄁飾区」と奈良県にある「葛󠄀城市」はどちらも同じ「葛（カツ）」という字が使われていますが、よく見ると文字の形が違っています。
これらの意味としては同じだけど、字形が異なる文字は異体字と呼ばれており、「沢」と「澤」のような分かりやすいものから、「はしご高（髙）」や「立つ崎（﨑）」などの細かい字形が違うものなど様々なものがあります。

日本人には切っても切り離せないこの異体字、Webで扱おうとするとなかなかハードルが高いです。
しかし、実はこの異体字を扱う仕組みは世界中で使われるようになってきており、今ではいくらか制限はありますが、Webでもこれらの漢字が扱えるようになり始めています。
このセッションでは、異体字とはなんなのか、PHPで異体字を扱うためにどんな苦労をした(している)のかを話したいと思います。

話す事
・異体字とは
・異体字がパソコン上でどう扱われているのか
・異体字と外字について
・異体字を読み書きする為の方法
・異体字をPHPで扱う時に困ったこととか

GitHub 上で PHP の関数やクラスにマウスをあてるとポップアップが表示され、該当の引数の数や、サマリを表示したりマニュアルに飛べたりする Chrome 拡張機能の GitHub PHP Function Jumper の開発の苦労話からどのように作ったのか、 Chrome Web Store への公開、そして今後の展望をノンストップでお届けします。

https://chrome.google.com/webstore/detail/github-php-function-jumpe/pmgmgaejgbjiooiklinoelilmnldlhcf

お伝えしたいこと

「意味を読み取りやすいコード」や「同じ事を同じ書き方で表現させる」のは、チームでの品質保持や生産性につながります。
それらの課題は、ある程度まで仕組みで解決することが可能です。

Enumぽいものは、比較的スモールに導入できる上にととても便利なので、作っちゃいましょう or 既存のモノを導入しましょう。活用事例としてDTOのお話にも触れます。

// users.statusが3だったら仮登録状態
if ($user->status === 3) {
こんな光景を、見た事がありますか。

PHPにはEnum型はありませんがEnumを模した実装は多くあります。
Hirakuさんの記事は読んだことのある方も多いと思いますし (https://qiita.com/Hiraku/items/71e385b56dcaa37629fe) 、myclabs/php-enumは多くのパッケージで利用されています 。
過去に私も自作しました(https://speakerdeck.com/o0h/bye-bye-magic-number)。これはCakePHP3での事例ですが、作成・導入をした結果とした感想は「メチャクチャDXが上がる」です。どこであろうと似たような表現を同じインターフェイスで扱うことで、メンバー間の書かれるコードの均質性が上がりました。
また、EnumをDTOオブジェクトと繋ぎこむとその効果は更に拡大します。
例えば「DBから取ってきた値」「ユーザーリクエストで飛んできたjsonデータ」を自然に扱えるようになります。
dereuromark/cakephp-dto dereuromark/cakephp-dtoを利用しながら「どういう開発体験がもたらされるか」について考察します

平和な日々を送っていた企業に突然隕石が降ってきたら？
鶴の一声、メテオフォール型で始まったプロジェクト。

アジャイル、クリーンアーキテクチャ、DDD、マイクロサービス・・・

守られないスケジュール、失敗の数々。
モダン技術を取り入れたプロジェクトの行く末は？

それを乗り越えて生まれ変わっていく組織の姿をお伝えいたします。

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

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

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

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

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

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

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

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

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

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

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

■お話する内容

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

■お話しない内容

• 認証
• CI/CD

■関連技術

• Azure Functions
• Azure Storage
• Azure Cosmos DB

皆さんの職場では継続的なライブラリのアップデートができているでしょうか？
弊社では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の詳細の文法

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

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

注)この話はフィクションです。きっと。

■対象
・今最新を使っている人(メインターゲットです)
・これからやる人
・もうやって、あるある話を聞いて涙したい人

皆さん、バージョンアップしてますか？
PHPや、Laravel、古くなってきたからバージョンアップしよう。
よくある話ですね。

でも、何も考えずにプログラムを書くと、あとで痛い目を見ます。

これは、本当にあったかはわからない、バージョンアップで悲しみを背負った人の話。

■内容(変更あるかもしれません)
・vendor配下をいじった報い
・コードをコピペで拡張した悲しみ
・Laravelを見捨ててPHP上げたらLaravelがお亡くなりに
・テストコードなんてなかった
・このライブラリはもう居ない
・消えた機能
・見つからない変更点
・再度襲いかかるコピペの悲しみ

静的型付言語なら、こんな苦労はしないで済むのに！
そう思った経験は、ありませんか？
それを強く感じたため、PHPに変わる何かを探し始めました。
そして、以下の5つのチャレンジを行いました。

• チャレンジ1: Scalaを使ったチャットシステム
• チャレンジ2: Haskellを使った大陸間レプリケーションバッチ
• チャレンジ3: goを使ったメディアサービス
• チャレンジ4: pythonを使った推薦システム
• チャレンジ5: Kotlinを使ったカンファレンスアプリ

これらのチャレンジを通じて、どのような成果を達成できたか、そしてPHPと比べて良かった点と悪かった点について発表します。

PHP でも「型」に関する議論が盛り上がっている今、一度「型」についておさらいしてみませんか？
近年、主要なプログラミング言語の「型」を取り巻く環境が変化しています。もちろん PHP も例外ではなく、7.0 以降「型」に関する機能を強化しています。
PHP では型ヒントの強化や、Java ではローカル型推論が導入されるなど、さまざまな言語で「型」に関する機能が拡張されています。
この拡張の傾向としては、動的型付け言語(PHP, Python)は漸進的型付けを導入する、静的型付け言語(Java, C#)は型推論を導入するというのがよくみられます。
その結果、言語の型付けの方式に寄らず、必要な個所に型を記述するというスタイルに収束していきそうな気配すらあります。
しかし、両者の間で「型」そのものの扱いには明確に差があります。その差とは何でしょうか？その差は何をもたらすのでしょうか？
そして、PHP 上で「型」と向き合う時が来たとき、どのように付き合っていくのがいいのでしょうか？
このセッションでは、両者の「型」の進化をおさらいしながら、PHP がこれから「型」と付き合っていく上で得られるものや課題、PHPer が「型」とうまく付き合っていくための基礎知識についておなしします。