hirapi's blog

駆け出しwebエンジニアのなんでもないメモ書き

PHP Conferenve2018 聴講メモ #3 「アーキテクチャ設計とUX設計は同じなのか!!??」by 弁護士ドットコムさん

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドをご覧ください。

note.mu

アーキテクチャ設計とUX設計は同じなのか!!??

デザインマネージャー 金子 剛 / 弁護士ドットコム株式会社

テーマ

UXデザインとエンジニアリング

テイクホームメッセージ

  • ユーザーとプロダクトが直接かかわりあうことで双方向なカイゼンが生まれる
    間によくわからないものが入ると一方向のものになってしまう
  • UXデザインとアーキテクチャ設計は「複雑な現実を抽象化する」という意味では同じもの
  • UXデザインはデザイナーだけのものではない。エンジニアこそUXデザインを!!

内容めも

  • 共創:全職種でチーム組んでアジャイル開発している
    「何を作るか、どう作るか」の両輪。
  • スタイリスト → UXデザイナー へのキャリアチェンジが増えている
    スタイリスト = 目に見えるグラフィックを作る人。
    デザインするものがグラフィックからUX = 体験にシフトしている
  • 「UXデザイン」はデザイナーの専売ではない
    エンジニアが体験をデザインする、なんてこともあっていい。
  • UXデザイン?
    • 例:スターバックス(コーヒーではなく体験を売る)
      コーヒーではなく「笑顔の店員さんからコーヒーを受け取っておしゃれなソファでPCを開く」体験を売っている
    • 例:Slack
      システムそのもの・機能そのものではなく「みんなでわいわいチャットする」体験を売っている

UXデザイン

ユーザー → ??? → 実装

間に別の存在が入ると情報が落ちる。
エンジニアがUXデザインにも入ると、生により近い情報をつかって実装が行える。
→ エンジニアもUXデザインをやろう!

  • ユーザーは何者か?
    モデリング = 具体的な特徴を洗い出して抽象化する(例:擬人化)
  • 何を提供するのか?
  • どう行動してほしいか?
  • その行動をしてもらうには、何を満たせばいいか?
    Issueに落とせる
  • どう作ればいいか? ← エンジニアに一番馴染みがあるのはたぶんここ

ユーザーのモデリング

デザイン思考 → 「あの人は怒っている……『怒る』って何だ?」
現実の複雑なものを、特徴によって定義付けて抽象化する。
そういう意味で、UXデザインがやっていることはエンジニアと同じ。DDD本とか読むと「これデザイナーも考えてることだ!」と思う。

ユーザー中心設計 → 中間生成物(レポート)→ プロダクト
中間生成物はユーザーの情報からプロダクトへ一方に流れてくるもの。
それをはさまず、ユーザーとプロダクトが双方向にかかわりあうことでカイゼンが回せる。

参考図書

  • 『エンジニアのためのデザイン思考入門』
  • 『クリエイティブマインドセット
  • 『デザイン思考でゼロから1を作り出す』

質疑

  • 普段エンジニアとどういう会話してるか
    今はマネージャーだから直接現場に出てないけど、普通のスクラム体制だと思う。
    KPIを軸に今必要なものやどう実現するかをみんなで話してる。ホワイトボードにいろいろ書いてわいわい話す。
    やりたいことに対してエンジニアが技術を提案したりデザイナーがデザインを提案したり、といった感じ。

感想

発表内容自体が「複雑な現実を抽象化」を体現した議論ですごく面白かった。
デザイナーさんがDDD本読むって何事……と思ったけどだからこういう話ができるんだよなあ、周辺領域のインプットは人を深くする……。
個人的にいずれ企画サイドも手出したいと思ってたからちゃんと勉強しようと思った。

あとスライド、すごくおしゃれで素敵だった!!

PHP Conferenve2018 聴講メモ #2 「VOYAGEのエンジニア評価制度ってどんな感じなのか25分でミニ再演」by VOYAGE GROUPさん

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドやブログ等の公式資料をご覧ください。

VOYAGEのエンジニア評価制度ってどんな感じなのか25分でミニ再演

林 志嶺 / 株式会社VOYAGE GROUP

テーマ

VOYAGEの技術評価会
発表者・評価者が重視するポイント

PHPカンファレンス2018で技術力評価会を再演します!企業ブースでは評価資料の公開も! - VOYAGE GROUP techlog

テイクホームメッセージ

  • 技術評価会:地味かもしれないけどがんばったことを説明する
    • 準備(非評価者 + アドバイザー) → 発表(評価者2名) → 評価すり合わせ → フィードバック → 昇格
    • 評価者の総評は社内公開される。1日くらいかけて書く。
  • 発表内容・評価
    • 背景ややった内容について、理由を明確にする
    • 評価者はやらなかったことも確認する → 意思決定全体を説明することになる
    • 実際の設計やコードも評価に含める
    • 前回からの成長も評価ポイント
  • 評価は褒めるが基本。改善余地のあるところはアドバイスをつける
  • 評価は本質ではない、評価を恐れずに本質的な仕事をしよう!

内容めも

VOYAGE GROUP

  • 広告:SAP, SSP。月間数百億imp。ログは1日でテラバイト単位に。。。
  • ポイントメディア:1,400万人の会員
  • インキュベーション:いろんな分野

評価制度

  • 地味にがんばったこと、そもそも評価されにくい

    • ライブラリのアプデ、アラートの撲滅
    • 仕様把握・要件定義のフェーズも、がんばっても理解されない
      → 「がんばったけど、実はたいしたことなかったのかな……?」へこむ
  • 技術力評価会
    準備 → 発表・評価(実演30分&質疑60分。評価者2名)→ 評価すり合わせ → フィードバック → 昇格!

再演!

準備段階で、アドバイザーと一緒にマークダウン1枚で概要・背景・やったこと(進め方・実装)をまとめる。
背景は特に他の人には見えにくいので、力を入れて説明。評価者も重視する。

準備資料を元に、評価者の前で説明↓↓

  • テーマ:ポイントメディアにおける運用タスクである「ポイント失効」の自動化
    運用タスク全体は告知・減算処理・経理報告。間違えると大事故になる部分。
  • 背景:減算処理、間違えられない作業かつ大変だったから自動化したかった
  • 制約:スケジュール、人員の面での制約
    評価者「なぜそういう制約が?」
  • 解決スコープ
    • 提案したこと、工夫したことのアピール
    • 今回やること・その理由:○○までに〜をやる、その後☓☓までに〜をやる
      評価者「ドキュメントはあったの?」「誰とどう進めたの?」
    • 今回やらないこと・その理由:
      評価者「この内容、やるとしたらどれくらいかかるの?」
      やったことは見えるけど、やらなかったことは見えない。どういう案を出してどういう意思決定を行ったか、説明するし質問する。
  • システム構築
    • 設計、技術選定、コード
      評価者「なんでこの言語を選んだの? 別のこういう選択肢もあったと思うけど」
      考え方だけでなく、コードも評価に含める。**
  • 評価してほしいポイント
    評価者「新旧バッチで結果が異なっていたら一大事。どうやって一致を確認した?」
    (被評価者「対象ユーザー数など集計値の確認、ランダムサンプルでいくつか個別チェック」

終わったら評価者が総評。社内に公開されるため1日くらいかけて書く。
ダメ出しではなく良いところの評価がメイン、加えて「こうできるともっと成長できるよ」をコメント。

評価を恐れず、本質的な仕事を! それぞれの環境でがんばっていきましょう。

質疑

Twitter上で募集して、後日ブログで回答してくださるそうです!

感想

発表者の方が被評価者として話をして、評価者の方が質問しつつ、また別の方がオーディエンス向けに解説してくださるスタイルだった。
壇上の被評価者が答えに窮する場面もあって、これガチでやってるなと。すごい。

ちょっと前までまさに「外から見えない意思決定」にけっこうな労力割いてたから、それをきちんと説明できる場があってうれしい気持ちよくわかる。。。
自分のいた環境と違うのは「評価が全社に公開される」っていう点。給料が上がっても昇格しても、具体的にどこでどういう努力と成果を上げたのか外から見えなければ"席の離れた"人とポジティブな関係が作りにくい。
オープンな文化憧れるなー、1月のも聞いてみようかな。

PHP Conferenve2018 聴講メモ #1 「独立したコアレイヤパターンによる PHP アプリケーションの実装」by shin1x1さん

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライド等の公式資料をご覧ください。 (スライド公開してくださるそうです!)

独立したコアレイヤパターンによる PHP アプリケーションの実装

@shin1x1

サンプルコード↓↓

github.com

テーマ

アプリケーションとフレームワークを分離するためのコアレイヤアーキテクチャ

テイクホームメッセージ

フレームワークを使うためにアプリケーションを作るのではなく、アプリケーションを作るためにフレームワークを使う

  • コアレイヤパターン
    • コアレイヤ:WHAT
      フレームワークに依存しない。外部とのやり取りについて必要なインタフェースを定義する。
      アプリケーションレイヤで使われているフレームワークが変わってもコアレイヤのコードは変えずに済むように作る。
    • アプリケーションレイヤ:HOW
      コアレイヤに定義されたインタフェースを、フレームワーク・ライブラリ等を使って実装する。
  • 実装
    サンプルコードのとおり。コアレイヤでインタフェースを定義した時点でテストを書く。
  • フレームワークを否定するものでは全くない。アプリケーションを作るためにフレームワークをうまく使う。

内容めも

背景

フレームワーク使ってアプリケーション作るのは今や当たり前だから、いっしょくたに語られがち。
でもアプリケーションとフレームワークの関係性、距離感はちゃんと考える必要がある。

なぜなら対象ドメインが違うから。アプリケーションが解決しようとしている問題と、フレームワークが解決しようとしている問題は違う。

  • フレームワーク = 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クラスで実装してみた。

問題

まとめ

コアレイヤアーキテクチャは、アプリケーションとフレームワークを分離するためのパターン

おまけ

  • あくまで考えのひとつ
    抽象的な話は強くなりがちだけど、引き出しに入れておいていただければw

質疑

  • 開発途中は速度重視でフレームワーク依存になっちゃう状況もありそう、途中でコアクラスに分離するタイミングみたいなのは
    明確な基準は特に無い。。。でも最初からコアレイヤパターンに移行することを想定して作っておくと分離しやすいかも

(ほかにもたくさんあったけどまとめきれなかった)

感想

何度も強調されていた「フレームワークをうまく使うためにアプリケーションを作るわけではない。アプリケーションを作るためにフレームワークを使う」、これ自体も確かにそうって思ったしこれを設計に反映させるのも面白かった。
よく見るいくつかの同心円に但し書きがされてる系の図、どこが違うねんと思うこともたまにあったけど()うしろにある背景というか問題意識とか価値観とかってそれぞれあるんだなとも思ったり。

サンプルコードもわかりやすかったし話も楽しく聞けたし良いセッションでした、@shin1x1さんありがとうございましたー!

builderscon tokyo 2018で初めて大きな技術系カンファレンスに参加してみた感想

hirapi.hatenablog.jp

hirapi.hatenablog.jp

というわけで、知らなかった、をたくさん聞いてきた!!
初めてのカンファレンス参加で、話ついていけるかなーって不安だったわけだけど、予想通りついていけないことのが多かった(笑
でも自分の知らない話を聞いて、そこをきっかけに勉強するのも私みたいな駆け出しにとって良い刺激だと思う!

読まねば&勉強せねば色々あったけどまず取り掛かろうと思ったのは↓↓
(ほんと「そんなのもまともに知らないのかよ」って言われそうだけど)

  • デザインパターン
    @shinpei0213さんのトークが鮮やかすぎて。結城浩さんの本から読んでみようかな。。。
  • Linuxプログラミングインタフェース』
    目指せP山さん
  • 通信プロトコル
    『マスタリングTCP/IP入門編』を読んでからQUIC調べようかな、そのあと@kazuhoさんのスライドまた読む

不勉強なのを揺さぶられて心が折れそうだけど、今あきらめても何年か後に後悔するの目に見えてる。だからやる。
エンジニア選んでよかったし、もっとエンジニアしたいし、ずっとエンジニアでいたいと素直に思った。

公開されたスライドがまとめられたら全部読む。
素敵なトークをしてくださったスピーカーの皆様、本当にありがとうございました!!

フィードバック?

私てきにうれしかった・楽しかったとこと/困ったとこを並べてみる。いつかどこかで誰かの何かになれば!

  • うれしかった・楽しかった

    • おおよそタイムテーブルどおりにものごとが進んでた
      押しが続いてセッション間の移動が大変になるかと思ったけどそんなことなかった、部屋移動多かった身としてはありがたかった
    • 質疑のとき、スピーカーの方が質問を要約してくれた
      YouTube動画のためらしいけど、わかりやすくて助かった
    • 部屋別にハッシュタグがあった
      セッション別にTLを追えた!
    • 発表がスムーズだった
      接続できなくて開始が遅れる、みたいなの基本的に無かった。これ系って地味にストレスになるから良かったと思う
    • 後日フィードバック書ける
      専用ページから出せるフィードバック、1週間くらい書けるらしい。ゆっくり書きたい派としてはうれしい。
    • Wi-Fi安定してた
      1日目たまにつながりにくかったみたいだけど、私が回った部屋では安定してつながってた
    • 名札にアイコン
      特に誰と話したわけでもないんだけど、オンラインとオフラインがつながってる感じで良かった!
    • 朝採れうまい棒
      メルカリってこんなユーモラスな会社だったのねw
  • 困った
    ほとんど会場の問題説はあるけど一応書くだけ書いてみる。

    • 部屋がちょっとせまかった
      セッションに入るために並ぶとは思わなかった……。でもスタッフの方がうまく誘導されてて混乱は無かった!
    • 飲食禁止
      1つのホール以外は飲食できないの、ちょっと厳しかった。そのホールでフリードリンクだったのはめっちゃ助かったw
    • セッション中の困り事をスタッフさんに知らせる手立てが無い
      どこかで急に部屋の電気ついてスライド見えなくなったことがあった。
      「部屋の電気消して〜」ってツイートがTLに散見されてて私も同意だったんだけど消しに行けず……。
      スタッフさんにメッセージ送る手段があったらありがたかった。(意図があって電気つけたのかもしれないけど……)
      良い手段を発明できたら別のカンファとか、あと大学の授業とかでも使えそう。
    • オープニング・クロージングで前回開催時ネタと前夜祭ネタが目立った(?)
      と言いつつ私が気にしいなのが9割。前夜祭行きたかった……
    • 欲を言えばトーク別のハッシュタグが欲しい
      ブログ書くときに思い出しやすくなるかも。あととぅぎゃりやすそう。
      でも分けすぎるとかえってTL追いにくくなるのかなあ……

て感じかなあ。
こんなたくさんのスピーカーとスポンサーと来場者を数十人のスタッフさんでさばいてたのすごすぎでした、運営の皆様おつかれさまでした……!
(次回とか別のカンファレンス/勉強会とかでぜひスタッフやりたいと思った)

ブログを書くまでがビルコン

とのことだったので拙いメモと共にうおーって書いてみた。
ツイートとかブログ記事とかにリアクションもらえるとどこかつながった感があって良いw

ただ聞いて回ってただけなのにインプットの圧がすごすぎて体力つかった、このエネルギーをしっかり取り込んでエンジニアリングしていく!

builderscon tokyo 2018 2日目に参加してきた

builderscon.io

1日目 に引き続き2日目も行ってきた!
あえて知らないテーマに突っ込んでいった結果、わからない話も多かったけどそのぶん勉強欲もそそられた。

感想記事はまた別に立てるとして、聴いてきたトークは↓↓

トーク

次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス

次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス (Security, privacy, performance of the upcoming transport protocols) - builderscon tokyo 2018
by @kazuho さん
通信プロトコルの仕様を策定してる方のお話、ところどころ「ここは私が提案してて」というのが出てきて異次元だった……!
TLで解説・感想を追いながらわからない単語調べながら、Webエンジニアとしてこれはあかんという強い反省の念。
勉強します……

kazuhoさんがスライドとともに記事をあげていらしたので貼らせていただきます↓↓

blog.kazuhooku.com

高集積コンテナホスティングにおけるボトルネックとその解法

高集積コンテナホスティングにおけるボトルネックとその解法 - builderscon tokyo 2018
by @pyama86 さん
なんかすごいテクニックとかあるのかなあと思って行ったら「測定 → バックトレース → ソース読む」の地道かつ高度なパフォーマンスチューニングだった。
最後におっしゃっていた「基礎的学習が大事」っていうのがすごく響いた。
Linuxプログラミングインタフェース』読まないと……。

hirapi.hatenablog.jp

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ - builderscon tokyo 2018
by @aereal さん
なるほど……なるほど……! ってずっと思ってた。
一部のレコード(証明書期限の近いドメイン)を対象にするとき、アプリケーション側が条件付けてDBに検索かけるのではなくて、
対象となるデータが生まれた(証明書の期限が近くなった)ときDB側からシグナルを送ることで、アプリケーション側は「対象のレコードを探す」という処理から解放される、
ていうの目からウロコだった。
1日目のairflowでも思ったけど非同期で処理進めるバッチ処理うまいこと作りたいな、でそれを「ピタゴラスイッチ」て呼ぶの好きだった(笑

hirapi.hatenablog.jp

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
子供心みたいなものをみんなで思い出す良い場だった(笑

hirapi.hatenablog.jp

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

印象的かつスライド見つけられたトークをいくつか↓↓

hirapi.hatenablog.jp

こうして見るとたくさん聞いたな……2日間ものすごいインプットがあった、うまく処理してアウトプットに活かしていかねば。

builderscon tokyo 2018 聴講メモ #8「Lightning Talks」

2日目最後のLT大会もめちゃくちゃ面白かったので、見つけたスライドと感想をちょこっと!

チームでテストを書くために

speakerdeck.com

by Masashi Hirano さん
指示するだけのBossではなく、率先して実行するLeader。すごく勇気と根気が要ることをやって結果が出てるのすごい、見習いたい。
チームメンバーから改善の意見が出るのってすごく嬉しいだろうなあ。
実は昔バイトしてた(大学が忙しくなってフェードアウトしてしまった)会社さんなのでちょっと「おおっ」って思った(笑

cpanfileがRubyでパースできることに気づいた俺たちは

www.slideshare.net

by @onk さん
これはまさかすぎて笑ったw いや確かにそうかもしれないけどやる!?ww
「評価してみます!」からの実演 → 会場「おおー」w
こういうノリ持っていたいなー楽しかった。

Development Tools for Next Generation

speakerdeck.com

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さん

speakerdeck.com

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくは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
  • 防ぐ

    • CAPTCHA
      テイラー・スウィフトの場合、視聴の度にボタン押させるのは現実的でなかった
    • DOMをランダム化する
    • 変数名を変える
    • リクエストのvalidation
      1分の動画について1分間に1回より多く視聴されることはありえない
    • shadow banning:リクエストの成否をあえて返さない(常に success:true

質疑

  • 余罪は 基本はちゃんとやってますw でも楽しいし、色んなツールをさわってみるのは良いこと

テイラー・スウィフト側から熱烈なファン認定されて、エンジニアとしてインターンのオファー来た(けど仕事あったから断った)。
うまくいったときは「計 画 通 り」(あの顔 アニメver.)← DEATH NOTE好き

感想

ローカルに立てた疑似動画再生サイトで実演しながらの講演、再生数カウントが増えたときにはみんなで「おおー」w
誰もが一度は持ったことのある(と私は思う)ちょっと悪いことをこっそりやってきゃっきゃするあの感じ、すごくチャーミングで楽しかった!w
エンジニアリングが仕事になって義務になって、忘れてた最初のどきどきを思い出させてくれる良いトークだった……!