週報 2017/11/05週 さっそく1回飛ばしました

今週やったこと

インプット

テスト駆動開発

テスト駆動開発

  • 引き続き読書中。来週社内で読書感想会をやる予定

その幸運は偶然ではないんです!

その幸運は偶然ではないんです!

  • だいたい読んだ。なんというか「こういう考え方もあるよ!」くらいの割と軽い本だった

アウトプット

第一回FFLTでCSVについて話してきた

LT資料

KPT

Keep

  • LT良かった。刺激を受ける

Problem

  • 運動不足。精神的に影響を受けるので定期的に運動したい

Try

  • 週1で筋トレに行く
  • TDD本の感想blogにまとめる

第一回FFLTでCSVについて話してきた

FFLT って何よ

エンジニアの情報発信や交流を深めるために、feedforce Lightning Talks (FFLT) を開催します!:tada:

弊社内のエンジニア同士でLT大会して、情報発信力をつけたり、他チームの知見を取り入れたり、交流したりしようぜ! という会でした

参加した感想

主催メンバーの やったことに価値がある。結果は大事だが、そもそも打席に立ってバットを振らないとヒットもホームランも出ない と言う言葉に大変感銘を受けました

最近「ブランド・ハップンスタンス理論」の本を読んでいまして、 それは キャリアの機転の8割は計画したものでは無く、運や偶然に左右されるもの と捉えて、その運や偶然を拾うために、とにかく色んな偶然が起こるように色んなチャレンジをしてみようぜ! という思想なのですが、とにかく「打席に立たないとヒットもホームランも出ないよね」という主催メンバーの話も似た話だなぁと感じました

その幸運は偶然ではないんです!

その幸運は偶然ではないんです!

↑タイトルがインチキ啓発本っぽいのがアレですが、まあまあ面白かったです

はっぴょう資料

CSVRFCみんな読んでね! というお話をしました

頂いた感想

パンチカードについては、CSVと別に以下のお話をしました

  • ascii の 0x7F は、パンチカードで「この列は間違えたので、全部穴を明けて消した」を意味する文字コード

TRY

CSVのパースは OCaml だと効率良く出来そう。というお話を頂いたので、少し見てみることにします

参考資料

CSVRFC

CSVファイルの一般的書式 (RFC4180 日本語訳) - アルプス登山の玄関口・笠井家

最後のおまけで話した、CSV の liberal_parsingオプションと、不具合について

ruby 2.4.0 CSV の liberal_parsing オプションについて調査してみた - Qiita

LTで少し話した、rubyのCSVLibraryと、splitした場合の速度比較について

いじょうです

そんな感じでした! FFLT立ち上げ、実行メンバーの皆さん本当にありがとうございました!

次回は何を話そうかな...

2017/10/23週 週報はじめてみます

週報仲間 を読んで、プライベートの週報って面白いなと思って真似してみた

今週やったこと

インプット

主に読書

喧嘩両成敗の誕生 (講談社選書メチエ)

喧嘩両成敗の誕生 (講談社選書メチエ)

  • 趣味。室町時代のバイオレンス感が知りたくて読み始めた

テスト駆動開発

テスト駆動開発

  • 仕事。TLで何度も再販される話を見たので、TDDを理解し直そうと思い購入

その幸運は偶然ではないんです!

その幸運は偶然ではないんです!

  • 仕事。自分のキャリアの今後について、どうしたもんかヒントが欲しくて購入

アウトプット

雑な読書メモをモーメントにアウトプットしてみた

KPT

Keep

どうせTwitter滞在時間が長いなら、インプット/アウトプットを全てTwitter上でやってみたら、なかなか良かった

TDD本。自分の中のTDDの認識にずれがあったのが修正出来てよかった。余裕があったら写経もしたい

計画的偶発性理論というキャリアの築き方が自分の人生観と近かった。より深掘りしたい

副業。時間が上手く使えるようになった

  • 1回に何時間も掛けるのではなく、気楽に1Hでもやれたら良いと思ったらできるようになった
  • 心理的ハードルを下げるのだいじ

休日にしっかり昼寝をしたら精神的な回復量が大きかった

  • なるべく時間を確保するようにしてみる

Problem

ニンジャ学会活動で、参加メンバーの把握漏れが発生

Try

TDD本の感想をまとめる

  • 社内で読んだ人も多そうなので、読書感想会をやりたい

ニンジャ学会活動をgithubでissue化してTODO管理する

今後の予定

Guradを使っている時に自分の環境だけrubocopのExcludeを変えたい時に見るページ

自分用においていて、別に rubocop によるチェックが不要なファイルがあったのでメモ

方法

  • Guardfile の rubocop の設定にオプションをつけて、自前の rubocop_local.yml を使うようにする
  • rubocop_local.yml の中で、 rubocop.ymlinherit_from する
  • その後に、独自の設定を書く

コード

Guardfile

guard :rubocop, cli: '-c .rubocop_local.yml' do
  watch(/.+\.rb$/)
  watch(/.+\.rake$/) # .rakeファイルも監視対象にする
  watch(%r{(?:.+/)?\.rubocop\.yml$}) { |m| File.dirname(m[0]) }
end

.rubocop_local.yml

inherit_from: .rubocop.yml

AllCops:
  Exclude:
    - 'Guardfile'
    # 他に `rubocop.yml` にある `Exclude` もコピー

エイリアスを使えばもっとかっこよくできそうだけれど、そのために本体のコードをいじるのも違うと思ったので一旦ここまで

web広告の配信関係の用語おぼえがき

web広告業界の人間に(数ヶ月前から)なったのに用語を全然理解していないのでメモ

純広告

広告主が広告媒体と直接契約をして掲載する広告

  • 昔、個人のテキストサイトにスポンサーがついてバナー広告貼られたりしたよね

アドネットワーク

複数の広告媒体を束ねて、広告を配信する仕組み

参考: アドネットワーク - Wikipedia

アドエクスチェンジ

複数のアドネットワーク同士が余った広告掲載枠を交換できるようにした仕組み

SSP

Supply Side Platform

広告媒体側が使う。複数のアドネットワークから、一番利益が出るところに広告枠を出稿する仕組み

DSP

Demand Side Platform

広告配信側が使う。複数のアドネットワークから、条件を満たす中で一番効果が出る/安いところに広告枠に出稿する仕組み

  • アドエクスチェンジとDSPの存在で、出稿時のフォーマットや課金方式は統一されていった

RTB

Real Time Bidding

アドエクスチェンジやDSPが使用している課金方式

RTBのしくみ

  • ユーザが広告媒体を含むページにアクセスする
  • アドエクスチェンジは、ユーザの情報(地域、どういう種類のページを見ているか、とか)を広告主に配信する
  • それぞれの広告主は、そのユーザに広告を表示するのにいくら払うか? を提示する
  • 最高金額を支払った広告主の広告を表示する
  • その間100ms!

Real-time bidding - Wikipedia

DMP

Data Management Platform

DMPでRTBを実行するに当たって、入札方針を適切にマネジメントしてくれるサービス

  • 最適な入札方針を決定するにあたって、膨大なデータを解析している
  • オープンDMPとプライベートDMPがある
    • オープンDMP : DMPが保有しているデータ(こういうユーザはこういうものを買うやすいとか)を元に解析する
    • プライベートDMP : 広告主が持っているデータ(購買データ、行動履歴など)と、オープンデータを組み合わせて解析する
  • DMPをやる技術的な敷居は高い
    • データを元に適切な配信を行うアルゴリズムの実装
    • RTBサーバとのやりとりのため高レスポンスなソフトウェア/ハードが必要

参考:

データエクスチェンジ

複数あるDMP業者を横断して適切に配信してくれるサービス

感想

  • 複数乱立したサービスを統合するサービスが作られる。の繰り返しの歴史…

参考

web広告の指標関係の用語おぼえがき

web広告業界の人間に(数ヶ月前から)なったのに用語を全然理解していないのでメモ

(そもそも)広告の流れ

広告の表示(impression) → クリック → ページ流入 → 商品購入や会員登録など(Conversion)

上記の流れのボトルネック探しや、費用対効果の確認のための指標のためにいろんな用語がでてくるという認識

いろんな実数

PV: Page View

広告が表示されるwebページの閲覧数

IMP: IMPression

広告が表示された回数

  • 1PVで複数IMPがあったり、その逆もありえる

CV : ConVersion

求めるべき最終的な成果。製品のお買い上げだったり、会員登録だったり。クライアントによりいろいろ

いろんなレート

CVR : ConVersion Rate

訪問数の内、CVに至る割合

CVR = 訪問数/CV数

CTR : Click Through Rate

広告をクリックされる割合

IMP/クリック数

CPI : Click Per Install

広告クリックに対して、アプリがインストールされる割合

広告クリック数/インストール数

広告費用関係

CPM : Cost Per Mille

Mille (1000) impression 毎の広告費用

CPC: Cost Per Click

広告1クリックにかかる費用

  • 広告費/クリック数
  • もしくは、1クリック幾らという広告の費用 → クリック保証型広告
  • CPM * CVR / 1000でも計算可能

CPA : Cost Per Action/Cost Per Acquisition

CV1件に対してかかった広告費用

コスト/CV数

  • CVが売り上げに直結しないサイト向け(資料請求や会員登録がCVのサイトとか)

広告費用対効果の指標

ROAS: Return On Advertising Spend

広告費用の回収率

売上*100/コスト

  • CV単価が様々なサイト向け

ROI: Return on Investment

広告にかけたコストの何倍の利益があるのか? という指標 当然ながら100%を割ったら赤字

((コンバージョン数*CV毎の平均利益)-コスト)*100/コスト

かんそう

  • CCostClick の場合があるので紛らわしい

参考

nginx+pumaでRailsで動かす場合コネクションプールの数を増やさないと `ConnectionTimeoutError` が発生するよ

先に結論

pumaは worker * スレッド の数だけコネクションを使う

しかし、ActiveRecordのコネクションプールの数はデフォルトで 5

なので大抵不足する

コネクションが不足すると、DBへの接続リクエストは待ち状態に

待ち状態のまま一定時間が経過すると、ActiveRecord::ConnectionTimeoutError が発生

なので、ActiveRecordのコネクションプールを増やす必要がある

コネクションプールとは?

予め(今回の場合は)DBに接続しておいて、必要に応じてその接続を貸し与える仕組み

ActiveRecordのコネクションプールを増やす方法

config/database.ymlconnection_pool で設定

production:
  <<: *default
  database: <%= ENV['DB_NAME'] %>
  username: <%= ENV['USERNAME'] %>
  password: <%= ENV['PASSWORD'] %>
  host: <%= ENV['HOSTNAME'] %>
  port: <%= ENV['PORT'] %>%
  connection_pool: <%= ENV['MAX_CONNECTION_POOL'] || 5 %>

コネクションプールの数は、いくつが良いの?

puma の thread 数と同数とする。 database.yml に設定された pool の数はプロセスごとに確保される値なので、thread数を設定すれば十分。

ただし、 同時接続数が、DBの最大コネクション数を超えないこと

ElasticBeanstalkの場合

pumaのスレッド数は32

posgreSQLの最大コネクション数っていくつ?

RDSの(posgreSQL)の場合

DBInstanceClassMemory / 12582880 らしい

  • m1.smallで145とか
  • ElasticBeanstalkの場合、
    • pumaのworker数はコア数と同一なので、よっぽどアプリサーバとDBサーバの性能に差をつけなければ心配はなさそう

参考