PHP Conferenve2018 聴講メモ #1 「独立したコアレイヤパターンによる PHP アプリケーションの実装」by shin1x1さん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライド等の公式資料をご覧ください。 （スライド公開してくださるそうです！）
独立したコアレイヤパターンによる PHP アプリケーションの実装
サンプルコード↓↓
テーマ
アプリケーションとフレームワークを分離するためのコアレイヤアーキテクチャ
テイクホームメッセージ
フレームワークを使うためにアプリケーションを作るのではなく、アプリケーションを作るためにフレームワークを使う
- コアレイヤパターン
- 実装
サンプルコードのとおり。コアレイヤでインタフェースを定義した時点でテストを書く。 - フレームワークを否定するものでは全くない。アプリケーションを作るためにフレームワークをうまく使う。
内容めも
背景
フレームワーク使ってアプリケーション作るのは今や当たり前だから、いっしょくたに語られがち。
でもアプリケーションとフレームワークの関係性、距離感はちゃんと考える必要がある。
なぜなら対象ドメインが違うから。アプリケーションが解決しようとしている問題と、フレームワークが解決しようとしている問題は違う。
- フレームワーク = Webアプリケーション開発
- アプリケーション = いろんなサービス・システム（Webに限らない）
問題を解決するためにアプリケーションを作る。フレームワークをうまく使うためにアプリケーションを作るのではない。
いろんなアーキテクチャを試してみた↓↓
① MVC + Service
MVCはどうしてもFat Controller, Fat Modelが生まれる。
→ ユースケース、コアロジックを Service レイヤーに切り出すようにした
→ が、思ったほど分離できなかった② レイヤードアーキテクチャ
DDD界隈でよく言われること。アプリケーションが解こうとしている問題のドメインを分析して、それを中心におく。
でもアプリケーションの問題とフレームワークの問題が混ざってしまう。
アプリケーションによってはちょっと too much になることも。
※ 今日の話はアプリケーションの設計だけにフォーカス。ドメイン分析は重要だけど今日は射程外。
まだ問題が残る。そこで、↓↓をベースにした新しいアーキテクチャパターンを紹介
- WHAT と HOW をレイヤで分ける
- コアロジックと技術詳細（フレームワーク等）の分離
- 守るべきシンプルなルールのみを決める
どうせ個別の開発シーンでは人々それぞれの「自分流の○○アーキテクチャ」が生まれてくるから
コアレイヤパターン
- コアレイヤ：コアロジック = WHAT を実装
プレーンなPHPを想定。コアレイヤのみに依存。ユースケースやドメインモデルなど。 - アプリケーションレイヤ：HTTP, RDBMS, 外部API等々 = HOW
コアレイヤが利用する技術のためのインタフェースを提供。
最初は「サービスレイヤ」と名付けていた。コアロジックから見ると「HTTPというサービスを提供してくれるレイヤ」
でも「MVC + Service」で使っていた同じ語で違う意味になっちゃうし伝わりにくいし迷ってやめた。
コアレイヤを中心に、サービスレイヤが外部（HTTP・RDBMS・外部API）との通信を担う。
「サービスレイヤを Laravel から CakePHP に変えても、コアレイヤはそのまま使える」のが理想。
インタフェースを実装したアプリケーションレイヤをコアレイヤにわたす。
ここでいう「インタフェース」は処理の共通化ではなく、「『自分たちは何をしたいのか』を表明するために使う」ものとして存在するもの。
例えばコアレイヤが直接 Eloquent を使うとコアレイヤがアプリケーションレイヤに依存することになる。
（コアレイヤ → アプリケーションレイヤ（特定のライブラリ））
そうではなくて、アプリケーションレイヤにやってほしいことをインタフェースとして定義する。
アプリケーションレイヤがそのインタフェースを実装することで、アプリケーションレイヤがコアレイヤに依存するようにする。
（コアレイヤ ← アプリケーションレイヤ）DIP！
アプリケーションレイヤは、コアレイヤで定義したインタフェースを実装する。
実装例：顧客のポイント管理（加算）
GitHub - shin1x1/phpcon2018-independent-core-layer: PHP カンファレンス 2018 独立したコアレイヤパターン
Laravel の一般的なディレクトリ構成に packages/Acme/Point を追加
コアクラスの中で、データ操作のために2つのインタフェースを定義↓↓
- Query：read
- Command：write
↑↑定義した時点で、無名クラスを使ってテストを書く。
その後、アプリケーションレイヤの実装をする。
コアクラスは注入されたアプリケーションレイヤのメソッドを実行するだけ = 「やりたいこと」だけを書く。
アプリケーションレイヤは、インタフェースは2つだけど1クラスで実装してみた。
問題
- レイヤ分けに迷う
例：トランザクション 制御をインタフェース化して、BEGIN/COMMIT/ROLLBACK はアプリケーションレイヤで実装 - コアレイヤへの入出力
ユースケースへの引数、戻り値のデータ型は自由。スカラー型かドメインモデルになる。
フレームワーク固有の型は避ける。
まとめ
コアレイヤアーキテクチャは、アプリケーションとフレームワークを分離するためのパターン
- シンプルなルール：コアクラスではフレームワークさわらない → レビューの視点が明確になる
- フレームワークやライブラリはもちろん大事！
ただフレームワークをうまく使うためにアプリケーションを作るわけではない。アプリケーションを作るためにフレームワークを使う。
おまけ
- あくまで考えのひとつ
抽象的な話は強くなりがちだけど、引き出しに入れておいていただければw
質疑
- 開発途中は速度重視でフレームワーク依存になっちゃう状況もありそう、途中でコアクラスに分離するタイミングみたいなのは
明確な基準は特に無い。。。でも最初からコアレイヤパターンに移行することを想定して作っておくと分離しやすいかも
（ほかにもたくさんあったけどまとめきれなかった）
感想
何度も強調されていた「フレームワークをうまく使うためにアプリケーションを作るわけではない。アプリケーションを作るためにフレームワークを使う」、これ自体も確かにそうって思ったしこれを設計に反映させるのも面白かった。
よく見るいくつかの同心円に但し書きがされてる系の図、どこが違うねんと思うこともたまにあったけど（）うしろにある背景というか問題意識とか価値観とかってそれぞれあるんだなとも思ったり。
サンプルコードもわかりやすかったし話も楽しく聞けたし良いセッションでした、@shin1x1さんありがとうございましたー！
builderscon tokyo 2018で初めて大きな技術系カンファレンスに参加してみた感想
知らなかったを聞いてくる〜 #builderscon pic.twitter.com/L2mQ7yD5vz
— hirapi (@chmv71) September 7, 2018
というわけで、知らなかった、をたくさん聞いてきた！！
初めてのカンファレンス参加で、話ついていけるかなーって不安だったわけだけど、予想通りついていけないことのが多かった（笑
でも自分の知らない話を聞いて、そこをきっかけに勉強するのも私みたいな駆け出しにとって良い刺激だと思う！
読まねば＆勉強せねば色々あったけどまず取り掛かろうと思ったのは↓↓
（ほんと「そんなのもまともに知らないのかよ」って言われそうだけど）
- デザインパターン
@shinpei0213さんのトークが鮮やかすぎて。結城浩さんの本から読んでみようかな。。。 - 『Linuxプログラミングインタフェース』
目指せP山さん - 通信プロトコル
『マスタリングTCP/IP入門編』を読んでからQUIC調べようかな、そのあと@kazuhoさんのスライドまた読む
不勉強なのを揺さぶられて心が折れそうだけど、今あきらめても何年か後に後悔するの目に見えてる。だからやる。
エンジニア選んでよかったし、もっとエンジニアしたいし、ずっとエンジニアでいたいと素直に思った。
公開されたスライドがまとめられたら全部読む。
素敵なトークをしてくださったスピーカーの皆様、本当にありがとうございました！！
フィードバック？
私てきにうれしかった・楽しかったとこと／困ったとこを並べてみる。いつかどこかで誰かの何かになれば！
うれしかった・楽しかった
- おおよそタイムテーブルどおりにものごとが進んでた
押しが続いてセッション間の移動が大変になるかと思ったけどそんなことなかった、部屋移動多かった身としてはありがたかった - 質疑のとき、スピーカーの方が質問を要約してくれた
YouTube動画のためらしいけど、わかりやすくて助かった - 部屋別にハッシュタグがあった
セッション別にTLを追えた！ - 発表がスムーズだった
接続できなくて開始が遅れる、みたいなの基本的に無かった。これ系って地味にストレスになるから良かったと思う - 後日フィードバック書ける
専用ページから出せるフィードバック、1週間くらい書けるらしい。ゆっくり書きたい派としてはうれしい。 - Wi-Fi安定してた
1日目たまにつながりにくかったみたいだけど、私が回った部屋では安定してつながってた - 名札にアイコン
特に誰と話したわけでもないんだけど、オンラインとオフラインがつながってる感じで良かった！ - 朝採れうまい棒
メルカリってこんなユーモラスな会社だったのねw
- おおよそタイムテーブルどおりにものごとが進んでた
困った
ほとんど会場の問題説はあるけど一応書くだけ書いてみる。- 部屋がちょっとせまかった
セッションに入るために並ぶとは思わなかった……。でもスタッフの方がうまく誘導されてて混乱は無かった！ - 飲食禁止
1つのホール以外は飲食できないの、ちょっと厳しかった。そのホールでフリードリンクだったのはめっちゃ助かったw - セッション中の困り事をスタッフさんに知らせる手立てが無い
どこかで急に部屋の電気ついてスライド見えなくなったことがあった。
「部屋の電気消して〜」ってツイートがTLに散見されてて私も同意だったんだけど消しに行けず……。
スタッフさんにメッセージ送る手段があったらありがたかった。（意図があって電気つけたのかもしれないけど……）
良い手段を発明できたら別のカンファとか、あと大学の授業とかでも使えそう。 - オープニング・クロージングで前回開催時ネタと前夜祭ネタが目立った（？）
と言いつつ私が気にしいなのが9割。前夜祭行きたかった…… - 欲を言えばトーク別のハッシュタグが欲しい
ブログ書くときに思い出しやすくなるかも。あととぅぎゃりやすそう。
でも分けすぎるとかえってTL追いにくくなるのかなあ……
- 部屋がちょっとせまかった
て感じかなあ。
こんなたくさんのスピーカーとスポンサーと来場者を数十人のスタッフさんでさばいてたのすごすぎでした、運営の皆様おつかれさまでした……！
（次回とか別のカンファレンス／勉強会とかでぜひスタッフやりたいと思った）
ブログを書くまでがビルコン
とのことだったので拙いメモと共にうおーって書いてみた。
ツイートとかブログ記事とかにリアクションもらえるとどこかつながった感があって良いw
ただ聞いて回ってただけなのにインプットの圧がすごすぎて体力つかった、このエネルギーをしっかり取り込んでエンジニアリングしていく！
builderscon tokyo 2018 2日目に参加してきた
1日目 に引き続き2日目も行ってきた！
あえて知らないテーマに突っ込んでいった結果、わからない話も多かったけどそのぶん勉強欲もそそられた。
感想記事はまた別に立てるとして、聴いてきたトークは↓↓
トーク
次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス
次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス (Security, privacy, performance of the upcoming transport protocols) - builderscon tokyo 2018
by @kazuho さん
通信プロトコルの仕様を策定してる方のお話、ところどころ「ここは私が提案してて」というのが出てきて異次元だった……！
TLで解説・感想を追いながらわからない単語調べながら、Webエンジニアとしてこれはあかんという強い反省の念。
勉強します……
kazuhoさんがスライドとともに記事をあげていらしたので貼らせていただきます↓↓
高集積コンテナホスティングにおけるボトルネックとその解法
高集積コンテナホスティングにおけるボトルネックとその解法 - builderscon tokyo 2018
by @pyama86 さん
なんかすごいテクニックとかあるのかなあと思って行ったら「測定 → バックトレース → ソース読む」の地道かつ高度なパフォーマンスチューニングだった。
最後におっしゃっていた「基礎的学習が大事」っていうのがすごく響いた。
『Linuxプログラミングインタフェース』読まないと……。
ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ
ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ - builderscon tokyo 2018
by @aereal さん
なるほど……なるほど……！ ってずっと思ってた。
一部のレコード（証明書期限の近いドメイン）を対象にするとき、アプリケーション側が条件付けてDBに検索かけるのではなくて、
対象となるデータが生まれた（証明書の期限が近くなった）ときDB側からシグナルを送ることで、アプリケーション側は「対象のレコードを探す」という処理から解放される、
ていうの目からウロコだった。
1日目のairflowでも思ったけど非同期で処理進めるバッチ処理うまいこと作りたいな、でそれを「ピタゴラスイッチ」て呼ぶの好きだった（笑
Using Chrome Developer Tools to hack your way into concerts
Using Chrome Developer Tools to hack your way into concerts - builderscon tokyo 2018
by @amyngyn さん
テイラー・スウィフトのチケットを取るためにMV再生サイトをハックする話。すごくチャーミングで面白いトークだった！w
MVたくさん見たユーザーのチケット当選確率を上げるっていうの、確かにhydeが同じことやったら私も同じチャレンジするかもしれない……w
子供心みたいなものをみんなで思い出す良い場だった（笑
1日約70万ビルド: DockerとNomadが支えるCI/CDプラットフォーム
1日約70万ビルド: DockerとNomadが支えるCI/CDプラットフォーム - builderscon tokyo 2018
by @kimhirokuni さん
CircleCIの中の人！ K8sが世界制覇する中で、1年前に選んだNomadの話。
CircleCI 1.0がたまに落ちる理由もあわせて解説してて、使ってたらもっと面白く聞けただろうなーとちょっと無念。
「K8sは小規模サービスには複雑すぎる」っていうところに自分がぶちあたったらNomadを検討してみようかな。
GirHubから落としてくるだけだから運用が楽っていうの魅力的だった。
スライドあげていらしたので貼らせていただきます↓↓
1日約70万ビルド: DockerとNomadが支えるCI/CDプラットフォーム - Speaker Deck
LT
LTと言いつつそうそうたるメンバーで、どのトークもLTにするにはもったいないくらい面白かった！！
数百人を前にLTとかすごいな……手震えそう……
ハッシュタグTLはここが一番楽しかったw
印象的かつスライド見つけられたトークをいくつか↓↓
こうして見るとたくさん聞いたな……2日間ものすごいインプットがあった、うまく処理してアウトプットに活かしていかねば。
builderscon tokyo 2018 聴講メモ #8「Lightning Talks」
2日目最後のLT大会もめちゃくちゃ面白かったので、見つけたスライドと感想をちょこっと！
チームでテストを書くために
by Masashi Hirano さん
指示するだけのBossではなく、率先して実行するLeader。すごく勇気と根気が要ることをやって結果が出てるのすごい、見習いたい。
チームメンバーから改善の意見が出るのってすごく嬉しいだろうなあ。
実は昔バイトしてた（大学が忙しくなってフェードアウトしてしまった）会社さんなのでちょっと「おおっ」って思った（笑
cpanfileがRubyでパースできることに気づいた俺たちは
www.slideshare.net
by @onk さん
これはまさかすぎて笑ったw いや確かにそうかもしれないけどやる！？ww
「評価してみます！」からの実演 → 会場「おおー」w
こういうノリ持っていたいなー楽しかった。
Development Tools for Next Generation
by @mizchi さん
Chromebookでも開発できるようにエディタを自作↓↓ すごい……
Next Editor
"git for everyone" は壮大な思想だ、デモ見てたらアクセスしやすい位置でぽちぽちしてcommit, pushできるみたいだった。
「エンジニアが転職しやすいのはGitHub Workflowで仕事が標準化されているから」はなるほどだった。
ネットワーク障害を支配したい話
www.slideshare.net
by HIRATA, Satoshiさん
ちょっと福岡disりすぎでは？？？w
擬似的にネットワーク障害を起こして対応の素振りをする、自分でサービス運用するときぜひやりたい……！
おまけ感覚でLT聞くつもりだったけど（すみません）本編レベルでテンション上がった！！
おつかれさまでしたー！
builderscon tokyo 2018 聴講メモ #7「Using Chrome Developer Tools to hack your way into concerts」by amyngynさん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
Using Chrome Developer Tools to hack your way into concerts
@amyngyn
テーマ
テイラー・スウィフトのPVを何度も再生することで、チケットの当選確率を上げる
テイクホームメッセージ
- Tools
- コンソール上でコード実行
- Network
- XHRを再現してみる
- curl
- メンタル
- 忍耐力
- 好奇心
内容めも
再生数の偽装には成功したものの、結局チケットは買わなかった
（炎上しそうなので最初に書いとく↑↑）
- 再生速度を上げて何度も再生する
ブラウザからサーバーへ「動画を見た」と伝えているはず
- 左上の窓からドメインをしぼって、Networkタブで通信内容を見る。
Youtubeからstart, countが送られる。countのレスポンス内容にsuccess:trueがある - 右クリックからXHRリクエストを再度送ると、レスポンスが
success:falseになった（駄目らしい） - Initiateタブからスタックトレース、リクエストを送るときの処理を確認する
id という変数に何か文字列が入っている、値は毎回変わる。ここが大事？ - curlで同じcountリクエストを投げてみる → 失敗
- start → count の流れが必要？
- start 投げてIDを獲得してからcount投げるといけるらしい、自動化できた
→ テイラー・スウィフトのファンとしてNo.1の立場を確立した！！w
- 左上の窓からドメインをしぼって、Networkタブで通信内容を見る。
防ぐ
- CAPTCHA
テイラー・スウィフトの場合、視聴の度にボタン押させるのは現実的でなかった - DOMをランダム化する
- 変数名を変える
- リクエストのvalidation
1分の動画について1分間に1回より多く視聴されることはありえない - shadow banning：リクエストの成否をあえて返さない（常に
success:true）
- CAPTCHA
質疑
- 余罪は 基本はちゃんとやってますw でも楽しいし、色んなツールをさわってみるのは良いこと
テイラー・スウィフト側から熱烈なファン認定されて、エンジニアとしてインターンのオファー来た（けど仕事あったから断った）。
うまくいったときは「計 画 通 り」（あの顔 アニメver.）← DEATH NOTE好き
感想
ローカルに立てた疑似動画再生サイトで実演しながらの講演、再生数カウントが増えたときにはみんなで「おおー」w
誰もが一度は持ったことのある（と私は思う）ちょっと悪いことをこっそりやってきゃっきゃするあの感じ、すごくチャーミングで楽しかった！w
エンジニアリングが仕事になって義務になって、忘れてた最初のどきどきを思い出させてくれる良いトークだった……！
builderscon tokyo 2018 聴講メモ #6「ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ」by aerealさん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ
@aereal
テーマ
テイクホームメッセージ
- バッチシステムについても、ソフトウェア構築一般の原則が使える
- 状態を持たない
- 分割統治
- ↑↑実現するための一例として、
- ワークフローエンジン：AWS StepFunctions
- pub/subをサポートするデータストア：DynamoDB
内容めも
- Let's encrypt
APIで証明書発行が可能
← はてなから寄付も。これから継続していく 万単位のドメイン。発行・管理を自動化しないと有料プランのサービスとしてきつい
配信の要件
発行の要件
発行の実装
更新の実装
考察：ピタゴラスイッチ
巨大なバッチの難しさ- 全体でどれだけあって、どこで失敗しうる／したのか把握しにくい
全体がわからないとどこにどう手を入れていいかわからなくなる - 巨大なバッチ、扱うデータ量が巨大 → 処理時間が長くなる。成功／失敗のログが必要
- 全体でどれだけあって、どこで失敗しうる／したのか把握しにくい
さいきょうのピタゴラスイッチ
- ワークフローエンジンの導入
- 分割統治
バッチ処理側がデータの状態を気にしなくていいようにする
アプリケーション書くときは意識できてるのに、なぜバッチ設計ではできないのか？- 合成可能ではない
合成可能なバッチ
質疑
- SFnのテスト
ダミーのLamdaを呼び出すようにして動かしてみた - TTL Triggerで失敗したとき、DynamoDBから消えているからリトライできてないんでは？
TTLを仕込んだテーブルと仕込んでないテーブルの2つがある。
TTLは証明書の期限より2週間くらい早く設定している。
リトライにも失敗したらMackerelから通知が来るのでログを元に手動対応。 - proxyのリロード、メモリにのっていたもの消えちゃうんでは？
proxyのリロード = nginxのプロセス再起動。memcachedにのっているのでnginxを立ち上げ直しても影響はしない。
memcachedにも無かったらDynamoDBに取りに行くが、そのときの遅延も許容範囲内だった。 - AWS SFnの設定をJSONで書くの、気持ちのいいもの？w
全体でどういう状態があるか、みたいなスキーマが特に無いから今は平気。
だけどミスったときに検知できない。バッチ側から可能的な状態一覧を生成するようにしたい。。。
感想
ソフトウェア設計の考え方をこういうシステム設計に適用するっていうの、ちらちら思ってたけど全然実現できてなくてすごく参考になった。
TTL Triggerみたいなマネージドサービスの機能をきれいに使ってるの見て、自分の思考がアプリケーション（プログラム）の中に閉じてたのに気づいた。
解くべき問題（要件）をまとめた後、何が最短経路かを構成全部から考えられるようになりたい。
こういう設計力、勉強というより実際のサービス設計・運用とかその過程でのディスカッションとかから得られるのかなあ。
日常にディスカッションが足りない……。
builderscon tokyo 2018 聴講メモ #5「高集積コンテナホスティングにおけるボトルネックとその解法」by P山さん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
高集積コンテナホスティングにおけるボトルネックとその解法
@pyama86
GMOペパボ ホスティング事業部
ロリポップ！ マネージドクラウド
テーマ
- 7分であなたもコンテナーマイスター講座
- はまった問題
- 展望
テイクホームメッセージ
- コンテナのボトルネックはLinuxコマンドを駆使してあたりをつけて解決する
- そのシステムコールが何をするのか、基礎的学習が必要（manを読んでわかるように）
『Linuxプログラミングインタフェース』
内容めも
コンテナ = プロセス
FastContainerアーキテクチャ
事象：監視コンテナのダウン
事象：コンテナが起動しない
- bridgeにインタフェース追加するとき：1025になっている。上限ぽいな
- BR_PORT_BITS：10 ← 1つのbridgeに2の10乗がポートの上限
- bridgeを分散させる
事象：CPU・メモリには余裕があるのにLAが高い
- cadviser：google製コンテナリソース管理
- gdb → bt（back trace）
- iproute2でnetlinkを利用したNSID取得 ← 最新のソースでは取得していなかった
もともと、ディストリビューションが配布しているパッケージでインストールしていた - 取得しないようにしたら2秒→0.05秒へ
gdb 便利
ディストリビューション配布、意外と最新のソースと乖離している。詰まったらソース読んで見る4000コンテナ弱でメモリ枯渇 = リソース使い切れた！
システム調査コマンド valfrind
あるwordpressサイトにabかけたら別のサイトが落ちた
コンテナなのに……？
質疑
- 直感的に、コンテナの起動はI/O等に比べて負荷にはならなさそうだけど
うちではディスクI/Oは負荷にはなっていなかった - コンテナの起動速度（イメージによりそうだけど）
過負荷状態でなければ1秒以内。起動直前の状態をメモリにのせて、メモリから起動する方法を検証中 - iproute2入れ方
makeインストール
感想
「測定 → バックトレース → ソース読む」の流れ、言うは易し行うは難しだ……。インフラ屋さんすごい……。
今まで現職でもうわからんって匙を投げてたところをこういうふうに調べて直していけたらどんなに良いだろう。
ものを言うのは知識と努力だ、がんばろって思わせてくれた。
あと何より面白かった！w
こんな高い技術あってこんな楽しく話す人と働けたらめっちゃ楽しいだろうなーって、こういう人たちと一緒に働けるくらい勉強と経験を積まないとなーって思った。
