みなさん、こんにちは。
MDH(メディア広告部門)の平井です。
水泳&プール好きの筆者は
「としまえんプール」、「よみうりランド プールWAI」、「東京サマーランド」
「国営昭和記念公園レインボープール」、「大田区立萩中公園プール」、「アクアフィールド芝公園」「ホテルニューオータニ」、「京王プラザホテル」、「ホテルイースト21東京」といった屋外プールに早く行きたいです＞＜
今回の「LT Thursday」(技術者のスキルや知識共有のための勉強会)は、4人のエンジニアが下記のプレゼンを行いましたので、ご紹介させていただきます。
- Plant UMLはじめました
- Google Chrome Headless 雑感&比較
- JSSDKの現状普及
- AJA-DSPを掘り下げる
1. Plant UMLはじめました (MDH 阿部)
サーバーサイドエンジニアの阿部がPlant UMLについて発表しました。
Plant UMLはテキストベースで図を作成できるOSSです。
作成できる図は、シーケンス図、ユースケース図、クラス図、コンポーネント図といった図です。
PlantUMLを選んだ理由は以下の4点です。
- テキストベースなのでGithubで管理しやすい
- アカウント権限を気にせず修正可能
- AtomやIntelliJといったエディタやIDEにプラグインがあり図を表示できる
- ChromeにはPlantUML ViewerというChrome Extensionがあり図を表示できる
導入して良かったことは各種図の一元管理ができたことです。
逆に良くなかったことは細かい位置調整が難しいことです。
結局良いのか悪いのかでいうと、位置にこだわる図を避け、シーケンス図として使うのは良いとのことでした。
2. Google Chrome Headless 雑感&比較 (MDH 木田)
フロントサイドエンジニアの木田が「Google Chrome Headless」について発表しました。
Headless Chrome(Google Chrome Headless)とはブラウザのUIなしにGoogle Chromeを実行するツールです。Headless ChromeはChrome 59から搭載されました。
2017/05/11時点においては、まだStable版では使えず、Beta版、Dev版、Canary版のいずれかで使用することが可能です。
Headless Chromeを使用するのに必要なものは以下の3点です。
- Google Chrome(v59+)
- Node.js(v6.3.0+)
- chrome-remote-interface
なお、chrome-remote-interfaceはnodeのライブラリなのでnpm installします。
雑感として以下の3点が挙げられていました。
- Windows環境に対応してない(近日対応予定)
- APIのドキュメントがわかりにくい(公式サンプルが少ない)
- 記述に癖がありあまり洗練されていない(本番のテストとして使う気になれない)
なお、Headless Chromeと類似した機能を持つハイレベルブラウザオートメーションライブラリとしてNightmare.jsがあります。Nightmare.jsは命令記述がシンプルなPhantomJSのラッパーです。
実行環境はElectronベースのNode.js+Chromiumです。現状だと登場したばかりのHeadless ChromeよりNightmare.jsの方がコードが短く分かりやすくて簡単で便利です。
Headless Chromeは登場したばかりで各種フレームワークが対応していませんが、
ElectronではなくWindows+Chromeなどユーザーに近い環境でテストできることに価値があります。
Nightmare.jsのようにコードを記述しやすいライブラリが登場すれば、十分選択肢に入ります。
3. JSSDKの現状普及 (MDH 李)
フロントサイドエンジニアの李がMDHで開発しているJS製のSDKについて発表しました。
各SDKの特徴や不足点、および全体的な今後の方針について発表しました。
4. AJA-DSPを掘り下げる (MDH 片田)
サーバーサイドエンジニアの片田がAmebaDSPについて発表しました。
DSPを理解するにはSSP、DSPを理解した上で、広告枠、SSP、DSPの関係性を把握するのがよいと思います。
SSP(サプライサイドプラットフォーム)は、媒体社(メディア)の収益を最大化するプラットフォームです。
DSP(デマンドサイドプラットフォーム)は、広告主(アドバタイザー)の収益を最大化するプラットフォームです。
ユーザーが広告枠が掲載されたWebページにアクセスすると広告枠からSSPに広告リクエストがきます。SSPは複数のDSPにBIDリクエストを送ります。
BIDリクエストは「XXXなユーザーがWebページにアクセスしていますが、いくらで広告を表示しますか？」というリクエストです。そのBIDリクエストにはアクセスしてきたユーザーを識別するためのクッキーやIPアドレス、ブラウザやOS、そのほかにフロアプライスやフォーマットなどの広告枠の情報などが含まれます。
各DSPはそのBIDリクエストに応じて、「いくらで買うよ」という入札額の情報を含んだBIDレスポンスを返します。
SSPは各DSPからのBIDレスポンスを比較して勝者を決定します。
そしてSSPは勝者DSPに広告リクエストをし勝者DSPから広告レスポンスをしてもらい、それを広告枠に配信します。
なお、「リアルタイムにSSPとDSPがやりとりをして、1インプレッションごとに入札をする仕組み」をRTBと呼びます。RTBにはOpenRTBという標準規格があり、AmebaDSPでも「基本的には」OpenRTBに則ってレスポンスをします。
「基本的には」というのはSSPそれぞれで独自拡張しており、それらに合わせる必要があります。
したがって、各SSPとの接続が大変とのことでした。
以上、LT Thursdayレポートでした。
次回もお楽しみに。
Profile:
株式会社サイバーエージェント
Ameba統括本部 広告部門 アドテクノロジー局
平井 芳孝
▼メディア広告部門(MDH)
Ameba Ownd：https://ameba-ad-pr.amebaownd.com/
Facebook：https://www.facebook.com/AmebaAds.CyberAgent/
Twitter：https://twitter.com/amebaads_pr