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

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

方法

• Guardfile の rubocop の設定にオプションをつけて、自前の rubocop_local.yml を使うようにする
• rubocop_local.yml の中で、 rubocop.yml を inherit_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広告業界の人間に(数ヶ月前から)なったのに用語を全然理解していないのでメモ

純広告

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

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

アドネットワーク

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

• 中小の広告媒体の台頭。個人のblogやwebサイトでも簡単に媒体になれるようになった
• Google Adsense、Yahoo!リスティング広告

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

アドエクスチェンジ

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

• google DoubleClick Ad Exchange など
• facebookもやってたけど撤退 : ニュース拾い読み：Facebook Exchange、2016年11月までにサービスを終了予定 | Exchangewire Japan
• 他にも何社かあるっぽい Ad exchange - Wikipedia

SSP

Supply Side Platform

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

• Supply-side platform - Wikipedia

DSP

Demand Side Platform

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

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

RTB

Real Time Bidding

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

• 広告の需要と供給のバランスによりリアルタイムにインプレッション単価が上下する
• 広告の価格が劇的に減少した
• アドエクスチェンジとDSPの存在で、入札型インプレッション課金(表示毎に課金)が主流になった
• 金融工学の技術が広告業界に流れてきたことがキッカケらしい
  • DSP/RTB/SSPの取引形態 | DSP/RTB入門書特別公開 #2 | DSP/RTBオーディエンスターゲティング入門 | Web担当者Forum

RTBのしくみ

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

Real-time bidding - Wikipedia

DMP

Data Management Platform

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

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

参考:

• 株式会社サイバーエージェント アドテクスタジオの技術と開発
  • サイバーエージェントもDMP事業をやってる
• 国内DMPの一覧と比較 ～DMPの実際の画面と使い方～｜デジタルマーケティングラボ

データエクスチェンジ

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

感想

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

参考

• Ad Exchange（アドエクスチェンジ）とは？を初心者にも分かりやすく解説します | マーケティングオートメーション SATORI
• 広告業界と無関係な僕がさっぱり理解できないアドテク用語を調べた。 | 三度の飯とエレクトロン

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/コスト

かんそう

• C が Cost と Click の場合があるので紛らわしい

参考

• ROIとは／「ROAS」「CPA」「ROI」を理解してリスティング広告の正しい効果測定を | スポンサードサーチ再入門 | Web担当者Forum
• CPMとはなにかを勉強してみる : ScaleOut

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

先に結論

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

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

なので大抵不足する

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

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

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

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

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

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

config/database.yml の connection_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数を設定すれば十分。

• nginx+puma+rails の worker,thread,connection pool 数の目安 - Qiita

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

ElasticBeanstalkの場合

pumaのスレッド数は32

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

RDSの(posgreSQL)の場合

DBInstanceClassMemory / 12582880 らしい

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

参考

• Concurrency and Database Connections in Ruby with ActiveRecord | Heroku Dev Center
  • だいたいこれ読めばOK。あとで翻訳したい…!
• PumaとUnicornで最近自分が理解したこと // Speaker Deck
• PumaでActiveRecordのErrorが出てハマった話 - 月曜日までに考えておきます
• Rails4.2のコネクションプールの実装を理解する - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
• nginx+puma+rails の worker,thread,connection pool 数の目安 - Qiita

「カンバン:ソフトウェア開発の変革」の読書メモ

カンバン:　ソフトウェア開発の変革

カンバン手法の目的って何?

• ワークフローの見える化による段階的なカイゼン
• 仕掛り(WIP)制限による労働&成果物の質の向上

アジャイル開発手法のような定義されたフレームワークではなく、チーム毎の状況に応じてプロセスを進化させていく

チーム毎の状況に応じてプロセスを進化させていくことのメリット

• 「できること」から始められるので、導入のハードルが低い
• 最終的に各チーム毎に最適なプロセスになる(現実とフレームワークの乖離による問題が発生しない

アジャイル開発手法のカードウォールとの違い

アジャイル開発でよく「カンバン」と言われているものは、仕掛りの明示的な制限が無く、新しい作業を引き取るルールが無い、ただの「見える化」である

仕掛り(WIP)制限のメリット

• ライフワークバランス向上
• 品質とパフォーマンスコストの向上
• ゆとりを作ることのメリット
  • 自主的なカイゼンが進む
  • 突発的な事象に対応可能になる
  • 問題解決に「群がる」ことが可能になる

最初は仕掛り制限を緩めに設定することで、チームの導入の反発を防ぐことができる

• ただし、仕掛り制限を無しにすると、カイゼンのスピードは大きく落ちると作者は言っている
• 仕掛り制限があることにより、発生する緊張や議論がカイゼンを促進するという持論らしい
  • 実感が無いのでよくわからん…

タスクボードを作る前にやること

• バリューストリーム(開発組織が実行する作業の流れ)を明確にする
• バリューストリームの入力と出力を定義する
• バリューストリームの作業項目を分析する
  • 作業項目の需要に合わせて、作業容量を割り当てる

タスクボードを作ったあとにやること

• タスクボードの前でのデイリースタンドアップMTG
• プロセスの振り返り/分析するための定期的なMTG
  • 上流/下流のチームのメトリクスを報告
• タスクボードのメトリクスを取る
  • メトリクスの目標となる値を決める
    • 平均リードタイム、スループットなど

メトリクスについて

メトリクスの目的

• 作業量の予測が可能になっているか?
• 組織がビジネス面で機敏に動けているか?
• 常にカイゼンが明確にあらわれているか?

結局カイゼンしたかどうかは数値にしないとわからないわけで、メトリクス超大事

メトリクスの方法いろいろ

累積フロー図

• 未処理項目/仕掛り/リリース済の累積数をグラフにする
• 「仕掛り」の部分の面積が一定であるならば順調
  • 自分達のチームの場合「待ち」の数も必要か

リードタイム

• そのタスクが完了するまでに掛かった日数
• 目標を立てて、それから乖離したものを後で確認すると良い

納期パフォーマンス

• 納期がある作業をどれだけ納期までに完了できたか?

スループット

• 特定の期間にデプロイされた項目数
• アジャイルのベロシティに近い

初期品質

• 見落とした欠陥の数

失敗による負荷

• 過去のデリバリー品質の低さが招いた作業項目の数

Amazon Lambda おぼえがき

いろいろ忘れるのでメモ

環境変数を使いたい

コードタブの下の方に入力するカラムがある

環境変数を暗号化したい

KMSを使って暗号化する方法がある

• KMSで認証情報を暗号化しLambda実行時に復号化する ｜ Developers.IO

このとき、ロールにKMSへのアクセス許可を設定する必要があるので注意

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "********",
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": [
                "arn:aws:kms:eu-central-1:********:key/********"
            ]
        }
    ]
}

callbackの内容がCloudWatchログに出力されない

ロールに権限が無いのが原因。CloudWatchLogsFullAccess でも渡しておくこと

ElasticBeanstalkでメモリ使用率が一定値を超えたらslackでアラートを出したい

ElasticBeanstalkでメモリ使用率やHDD残量をモニタリングする方法の続き

ざっくり解説

• ElasticBeanstalkの「アラーム」では、CloudWatchでメトリクスしている項目が設定した閾値を超えた時、AmazonSNSのSNSトピックに通知を渡すことができる
• AmazonSNSとは、何かをトリガーにしてどこかに情報をpushするサービス
  • 送信先は、Emailとか、特定のURLを叩くとか、Lambdaとかいろいろ
• SNSトピック : トリガーと送信先(Subscriptions:複数可)のセット

方法

例として、メモリ使用率が98%を超えたら通知する場合

まず、ElasticBeanstalkでメモリ使用率やHDD残量をモニタリングする方法で追加したカスタムメトリクスMaxMemoryUtilizationを「モニタリング」に追加する

モニタリングに追加されたら、グラフの右上のベルのマークを押す

アラームの追加に遷移するので

• 「しきい値」を設定する
• 「次の時間経過後に状態を変更」を設定する
  • 1分なら、1分後にしきい値以下になったらOKになる
• Slackの有料アカウントを使っているならば、Eメールアドレスにslack通知用のアドレスを設定すれば良い

Slackの有料アカウントを持っていない場合

こちらでAWS LambdaでSlackを叩く方法が解説されている

CloudWatchのAlertをAWS Lambda経由でSlackに飛ばす - Qiita

• AWS Lambda上で、Slack の WebHooksを叩くLambda functionを作成する
• 上記で作成されたSNSトピックに、このLambda functionを叩くSubscriptionを追加する

参考

• アラームの管理 - AWS Elastic Beanstalk