この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Action Cableをイケてる構成のrailsで使いこなそう

ActionCable 使ってますか？

Rails5以降から導入されたActionCable
公式ドキュメントではチャットの実装などで使われていますが、色々な使い方ができそうです
sidekiqに投げた処理の結果を非同期で受信するとか

執筆時点では世の中に知見が多くなかったので実装体験記を残します

導入

rails g channel hoge_channelでActionCable導入に必要なアレコレが生成されるよ
ただしcoffee scriptだしSprocketsのアセットパイプラインに乗る形でフロントのスクリプトが吐き出される
(Rails5.2の場合)

うちの案件はwebpack導入してるしcoffe scriptなんて書いた事無い
そんな場合は下記コマンドでライブラリを導入しましょう

yarn add actioncable
または
npm install actioncable

そしてベースとなるcable.jsはこんな感じに
自分はapp/javascripts/channelsディレクトリに設置しました

# app/javascripts/channels/cable.js

import cable from “actioncable”;

let consumer;

function createChannel(...args) {
  if (!consumer) {
    consumer = cable.createConsumer();
  }
  return consumer.subscriptions.create(...args);
}

export default createChannel;

各チャンネルのjsはこんな感じ

# app/javascripts/channels/test_channel.js
import createChannel from “./cable”;    //cable.jsのパスは適宜変更してください
$(function(){
  const channel = createChannel(“TestChannel”, {
    received(message) {
      alert(mesage); # この辺に受信時の処理を色々書く、今回は受信したものを取り敢えずブラウザにアラートとして表示する
    }
  });

  // rubyのactioncableで実装した処理を()呼ぶ
  function method_name(message) {
     channel.perform(“method_name”, { message });
  }
});

ruby側の実装は公式ドキュメントで紹介されている実装から特に変更点はないです

設定

よ～し取り敢えず検証用にデータを受信したらブラウザのアラートに出す機能作ったので動かしてみるか～
おや…動かん…エラーが出てるな

設定に不足がある場合はブラウザのデバッグコンソールに下記のようなエラーが表示されます

WebSocket handshake: unexpected response code: 502

または

WebSocket connection to 'wss://example.com' failed: WebSocket is 'test channel~js'
closed before the connection is estrablished.

色々な記事にdockerで動かしている場合は専用のコンテナ建てろみたいなことを書いていましたが検証の結果不要でした
自分の場合 config.reload_classes_only_on_change が false になっていました
windiwsで開発していた時に変更がホットリロードされなかったのでここの設定弄ったのですがaction_cableの挙動にかかわるようです

その他設定

config/cable.yml でdevelop環境もredisを使用する

development:
  adapter: redis
  url: redis://10.10.3.153:6381 => 方法は自由ですがsidekiqやセッション情報とは異なるURLになるように工夫しましょう
  channel_prefix: appname_development

test:
  adapter: async

production:
  adapter: redis
  url: redis://10.10.3.153:6381
  channel_prefix: appname_production

config/environment/production.rbで自分ドメインからのリクエストを許可する

config.action_cable.allowed_request_origins = ['https://rubyonrails.com', %r{http://ruby.*}]

config/application.rb でrailsアプリケーション上にマウントするパスを指定する

class Application < Rails::Application
  config.action_cable.mount_path = '/websocket'
end 

config/routes.rbにマウントするパスを指定する方法を紹介する記事も見かけましたがたぶんこっちの方が良いと思います

viewファイルのヘッダーに<%= csrf_meta_tags %>を記載する

その他開発環境の設定や本番サーバーの構成によって何かしらの設定が必要になる場合があります
nginxのconfigファイルにリクエストヘッダーの設定書くとか…

うまくAction Cableが動けばRailsコンソール立ち上げて用意したchannelクラスのメソッドを呼んでみるなりなんなりすれば動くはずです
パターンが膨大すぎて個別の症状に応じて苦戦するのはなんだかインフラエンジニアっぽい感じでした
つまりググっても出てこないエラーとの戦いが結構大変だった

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

What is the difference between pull request and merge request?

自分がされたり、自分がしたり

そのクエリ参照する変数宣言、一定の時しか必要ないよね？

def create_current_banner_info(user,  now = Time.now)
  user_items = user.items.pluck(:item_code, :quantity).to_h
  BannerMaster.holdings(now).each_with_object([]) do |banner, res|
  if banner.user_condition_need?
    case banner.condition_type
    when :fulfill_item
      next unless user_items[banner.neccesary_item_code].to_i >= banner.nessesary_quantity
    when ...
      ...
    end
  end
  res << banner.as_json(:code, :banner_type, :banner_icon, ...)
end

アイテムを保持しているかで表示するかを分けるバナーって複数あったりもするだろうけど、いつもある訳じゃないよね？
だったら一番上のuser_itemsはnilで宣言しちゃって、 when :fulfill_item の中に入ったところで||=で宣言すれば無駄ないと思うよ。
いやそれよりも、もっと良い方法あるな。
そもそもさ、複数あるって言っても、pluckして必要なデータの取得を最低限にしてると言ってもさ、全部のアイテム参照してるのかなり無駄じゃん。
バナーを表示するかとレスポンス作っているところを一緒くたにしないでさ、先にアイテムが必要なバナーだけを抽出してしまえば、その参照すべきアイテムコード群を取れるよね。そうすれば本当に必要最低限しか取らずに済むよ。
で、今すぐマージ必要？　必要じゃないか、分かった。じゃあお願いします。

先にグルーピングしましょう

def past_events_user_data(user, now = Time.now)
  events = EventMaster.ended(now)
  user_events = user.user_events.where(event_code: events.pluck(:code))
  events.map do |event|
    user_event = user_events.find{ |user_event| user_event.event_code == event.code}
    create_past_event_response(event, user_event)
  end
end

ソースコードの重みってクエリ参照が一番でかいけど、コード自体の重みも結構馬鹿にならないんだよ。
ここだと、eventsの数だけfindの線形探索が走っちゃうから計算量がO(n² ) であんまりよろしくない。
なのでuser_eventsを参照しているところで、index_by(&:event_code)をしておけば、後のfindを消せて、user_event = user_events[event.code] と綺麗に済ませられる。ハッシュ検索はO(1)だから、これなら計算量をO(n)まで落とせた。

混乱するかも

def lottery_apple(user, event_code, index)
  user_received_apples = user.user_apples.where.not(received_at: nil).where(event_code: event_code, apple_index: index)
  AppleMaster.lottery_no_duplicate(event_code, index, user_received_apples)
end

...

def lottery_orange(user, event_code, index)
  user_received_oranges = user.user_oranges.where.not(received_at: nil).where(event_code: event_code, orange_index: index)
  OrangeMaster.lottery_no_duplicate(event_code, index, user_received_oranges)
end

……あ、これ上のコードのindexと下のコードのindexの意味合い違うのね。
同じファイル内にあるソースならちゃんと変数名変えておいた方が良いと思うよ。

消すよりコメントアウトの方が時には良い

enum 1,  :new
enum 2,  :intensive
enum 3,  :course
enum 4,  :obliteration
enum 5,  :lenthal
enum 6,  :environmental
enum 8,  :search
enum 10, :end
enum 11, :alternate
enum 12, :dead_s

これ、7と9が抜けたの後から見たら理由が良く分からないしログ追うハメになるから、コメントアウトの方が良いかな。

後置ifはほどほどに

return long_method(argument1, argument2) unless too_long_long_methooooooooooooooooooooooood?(argument3, argument4)

流石にこれだと長いから、後置ifじゃなくて普通にif~endで囲もうか。その方が直感的な理解が早い。
というかrubocop怒られなかった？　……あら、無いのか。
付けようとすると……あー、駄目だ、案の定たっぷり出たわ出たわ。
issue化しておこうか(そして誰もやらない)。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

がんばろう

貴方はプロジェクトにアサインされ、サーバーの負荷試験を依頼された

「頑張るぞ！　ガルバンゾ！」

ここにコードがあった。それは見るからに不味そうなスパゲッティであった

「お？　おお……」

ここにスケジュールがあった。それはスパゲッティが腐るまでに時間がない事を示していた

「おお……。お、おお……」

それは即ち、根本解決をするだけの時間的猶予がない事を示していた

「おおあああああっ、うっ、うぐぅっ」

貴方の使命は、せめて足掻く事であった

「……」

現状整理から始めよう

　コードがスパゲッティになる理由は幾らかあれど、そんな事を調査していても始まらない。
　やるべき事は罪を償わせる事ではない。罪を代わりに償う事だ。
　まずは一つ一つ現状を整理し、問題解決には何をすべきか考える事である。

　現状を調査した結果、まずはとても良い事が分かった。

テストを書く文化がある

　これが何を意味するかというと、コードの振る舞いがテストによって保証されているという事だった。
　コードが中でどんなに破茶滅茶な事をしていても、テストが通りさえすればそのコードは少なくとも挙動としては正しい。
　即ち、中を書き換えてもテストが通りさえすればその正当性は保証される。最後にQAなどを通す必要はあるが、これから行う改修に対しての強力な道しるべとなる。

使用している監視ツールはデータベースの重みを調査するものと、サーバーそのものの重みを監視する二つを利用していた

　確かにこれで重い部分がある程度は分かる。ある程度ではあるが。
　これではコード全体の重みは一部見逃される恐れがある。レスポンスの遅さとは、データベースのクエリ以上にコードそのものの重みが原因となる場合があるからだ。
　ただ、それは誰かに何かを依頼する事もなく調査、解決出来る。
　そしてその監視ツールがある事自体はとても有用である、というか無ければ負荷試験は出来ない。

最も問題であるコードは1APIの中で何度も同じデータを参照する事があった

　マスタデータやユーザーデータを、そのコードが呼ばれる度に参照、計算して返していた。
　1回の呼び出しでユーザーデータが多数変更され、また都度都度必要となるマスタデータは変わる。それが1APIの間で何度も発生する。
　そしてまた、これを根本的に解決する事ーー例えば1回の呼び出しに纏めるーーといった事などは影響範囲や再度掛かるQAへのコストなども鑑みると時間の都合上不可能。
　出来るのは1回1回で掛かるコストを出来る限り減らす事、それが最善だった。

改善方針をまず固めて共有しよう

　見ての通り改善すべき事はデータベース上の重みとしてもコードとしてもはっきりしている。
　ただ、改善するものの規模が大きいのならば、見切り発車で改善を決めるのではなく、一旦共有して見落としが無いかなどを第三者の目からも含めて判定した方が良い。

「ここの重みを削れれば、取り敢えず重みは60%位になります」
「60%でもまだ重いな……他の部分は？」
「まだ調査していないです。ただ、ここのコードの重みとしては、このAPIの負荷の割合を見てもデータベースの重みではなく別の部分である事ははっきりしているのと、今のツールでは調査しきれない部分もあるので先にやってしまおうと思います」
「……まあ、良いか。で、どうやって削る？」
「基本的に1API間でユーザーデータを使い回す、1スレッドで同じマスタデータを使い回す、という感じですね」
「どうやって使い回す？」
「ユーザーデータに関してはのユーザーのインスタンスが1APIで使い回されているので、そこにインスタンス変数として保持しまおうかと。
　マスタデータもメモ化してしまいます。
　まあ、要するにユーザーデータ、マスタデータ共にスレッドのメモリにキャッシュします」
「……メモリに負荷が掛かるだろうけどそこ辺りは」
「幸いそちらはまだ余裕があります」
「オーケー」

改修したが想定までは減らなかった

「まあ、そう簡単に減らせたら苦労しないよなー……」
　確かに、無駄なデータ検索量は減った。幸いマスタをメモリに持たせる施策も、強いメモリ負荷もなく実現出来た。
　しかしながらAPIの重みを見ると、データベース起因ではない不明な重みが大半を占める事となっていた。
　これは即ち、コード自体に問題があるという事だ(掛けている負荷が適切であれば)。

　アプリケーションに対するプロファイリングツールを導入し確認してみると、膨大な配列から必要なデータを参照してくる部分に大きな問題があった。
　既存の部分だけではなく、自身が改善したユーザーデータやマスタデータを使い回す処理でも、その引っ張ってきたデータから目的のデータを探り当てる処理で重みが発生してしまっていた。
「データをDBからメモリ上にデータを乗せるだけではまだ駄目か……」
　こうなると、その検索処理などをどうにかするしかない。
　コードを読み込み、どのようにデータが扱われているかを確認していく。
・ある条件に当てはまるユーザーデータは、特殊な条件の場合にしか参照されない事が分かり、基本的に検索から抜いても良い事が判明した。
・同じマスタの中でも種類が膨大にあり、複雑な検索条件でもメモ化の形を工夫すれば配列検索の回数を減らせる事が分かった(マスタを分けろよという愚痴は心の奥底に仕舞った)。
　そんな事からユーザーデータやマスタデータを分類分けしていくと、何とかなりそうな目星がついてきた。

※ruby_on_railsだとindex_byやgroup_byがとても有用。単純にデータ検索をするにしても配列からfindを仕掛けるよりもハッシュにしてキーが存在するかを判定した方が確実に早いです。
サンプルに以下。

1.

array = (1..1000).to_a
begin
  now = Time.now
  1000.times do |n|
    array.include?(n + 1)
  end
  p Time.now - now
end
=> 0.0051824

2.

hash = (1..1000).each_with_object({}){|n, res| res[n] = true}
begin
  now = Time.now
  1000.times do |n|
    !!hash[n + 1]
  end
  p Time.now - now
end
=> 0.0001501

かなり改善された

「ここまで改善出来ました！」
「これなら耐えうるな、で、コードは？」
「こうなりました！」
「……複雑だな……」
「……そうなんです。まあ、テストコードがあったので振る舞いは保証されています」
「そうだな、そうか(テストコードの網羅率って100%だったかな……)」

　根本原因を解決出来ずに上部だけで対応しようとすると、そうなります。
　できる事はスパゲッティを美味しく作り直す事ではなく、防腐剤を振りかける事、ただそれだけだったのですから。
　しかしながら、そうしなければいけない時もあるのです。きっと。

美味しいスパゲッティの作り方

1. 厚切りの芽を抜いたニンニクと唐辛子をたっぷりのオリーブオイルで常温から弱火で炒めましょう
2. ニンニクはきつね色になったら取り出しましょう。唐辛子も焦げる前に取り出しましょう
3. 好きなキノコを好きなだけ入れて塩を振って炒めましょう
4. 塩をきつめに入れた熱湯で茹で上げたスパゲッティを和えましょう
5. 皿に盛り付けてから取っておいたニンニクと唐辛子と、あればパセリを意識高めに散らしましょう
6. 食べよう

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

セミナー概要

・カスタマーサクセスを意識したカスタマーサポートの方法
・顧客から高い満足度を得続けるカスタマーサポートの方法
・カスタマーサポートに適したサービスの選定方法

登壇者

• 弁護士ドットコム：三浦陽菜様「クラウドサインの新しいカスタマーサポートの方法」
• ベルフェイス：森本真伍様

クラウドサインの新しいカスタマーサポートの方法

• クラウドサインとは
  • クラウド型電子契約サービス
• リレーションの現状
  • チャットサポートの目標
    • 速さ
    • 満足度
  • 体制と測定方法
    • 3人体制
    • チャットの最後の満足度を聞く
  • 結果
    • 初回連絡60秒以内（満足する結果）
    • 満足度90%以上（満足する結果）
• 満足度とチャーンの結果
  • 満足度が低い顧客が解約しているわけではない
  • 解約している顧客はサポートに問い合わせがない
• サポートの意味は？
  • 関係を築き続けることが大事
• 関係を築き続けるには？
  • CX(カスタマーエクスペリエンス)の向上が大事
• CXとは？
  • 顧客に手間を取らせない（1回の連絡も手間）
• 手間を取らせない方法
  • 1.疑問が生まれない
  • 2.疑問を自分で解決できる
  • 3.疑問は聞けば分かる
• 「疑問を自分で解決できる」の現状
  • ヘルプセンターで解決できる
• 問題点
  • 存在の認知度が低い
  • チャットの方がラク
• 問題点の解決策
  • elevio
• elevioについて
  • 開発せずにツールチップ（はてなマーク）を設定可能
  • intercomと連携できる
  • elevioからアドバイスをいただける
• elevioをを使った今後の予定
  • データ収集
• まとめ
  • ユーザーに努力をさせないこと
  • 爆速で解決できること

ベルフェイスのカスタマーサポート

• ベルフェイスとは
  • インサイドセールスサービス
• カスタマーサポートの極意とは
  • 個に頼る
• KPIの達成状況
  • チャットの初動時間：60s以内（コツは画面と音）
  • 満足度：95%以上
  • (こちらからのアンケートなどに対しての)回答率：40%
• KPIと行動指針
  • カスタマーファースト
  • オーナーシップ
  • ハイスピード
  • 改善
  • 細部を大事に
  • メンバー内協力
• 具体的な対策
  • よかったことの共有
  • 満足度が低い対応への改善検討(メンバー全員で)
  • チャット対応のポイントを共有（docbase）
• 課題
  • 数値を正しくとる
• まとめ
  • 行動指針をCS向きにする

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Search Engineering Tech Talk 2019 Spring レポート

Search Engineering Tech Talk とは

検索技術勉強会の目的は、「検索」/「検索システム」にまつわる技術や手法に関して共有できる場を提供すること

登壇者

• ナビタイム 小式澤 篤 ：「安心な移動」のためのPOI(Point-of-Interest; 地点)検索
• 菅谷 信介 ：社内ドキュメント検索システム構築のノウハウ
• @818uuu ：料理動画アプリ「クラシル」の検索について

「安心な移動」のためのPOI(Point-of-Interest; 地点)検索

• POIとは
  • point of interest
  • 移動の目的地となる場所
  • 緯度軽度や名前や住所などの情報
• POIの特徴
  • 短文か単語が多い
  • 文章が少ない
  • 要素が多い
• 経路探索におけるPOI検索の立ち位置
  • 目的地検索ができなければ、そのあとのナビゲーションができない
• 安全な移動のためのPOI検索
  • ほとんどの人が上位５位を選択している
  • キーワードとの一致率が大事
• 問題点１
  • いろんな県のものが出てくる
    • ホテル椿山での検索でホテル椿山東京以外のホテル
    • ディズニーでの検索で東京ディズニーランド以外のもの
    • スカイツリーも同様
• 対策１
  • 人気なもの（有名度）が高いものを優先して上位に表示 →大方解決
• 問題点２
  • チェーン店などでの検索で、人気の店舗が上位されてしまう
  • 「コンビニ」での検索で、「セブンイレブン 新宿駅」が表示されるなど
• 対策２
  • 距離が近いものも優先して上位に表示 →大方解決
• まとめ
  • 並び順優先順位

1. 有名度
2. 適合率
3. 距離
4. 再現率

社内ドキュメント検索システム構築のノウハウ

• 企業内検索とは
  • 企業内の情報を検索する（ファイルサーバーやウェブウェイトなど）
• fessとは
  • オープンソースの全文検索システム
  • elasticsearchを使っている
• 企業内検索を構築する際のよくある課題
  • クロール対象が大規模
  • セキュア
  • 業務システムとの連携
  • ファイルが様々
• 大規模化について
  • ドキュメント数は数千万くらい
  • クラスタにして分散検索
  • クロールする際の工夫
  • 更新ファイルリストを生成し、更新されたもののみをクロールする（全件だと１日のクロールで終わらないため）
• セキュアについて
  • 認証状態により検索結果を出し分ける
    • ad連携
    • ログイン
  • クロール時に権限情報を付与する
    • 閲覧することができる権限をクロール時に取得するため
  • シングルサインオン
  • 検索システムにも自動でログインする
    • リバースプロキシがた
    • windows統合認証
    • openid connectなど
• 業務システムとの連携
  • データはデータベースにあるため、sqlを検索サーバーに入れる
• ファイルの種類について
  • ツールを使って文字列の抽出
    • ms office po
    • pdfbox
    • tika など

料理動画アプリ「クラシル」の検索について

• クラシルについて
  • 検索対象：動画
  • ドキュメント?数：約2万5千本
• 同義語対策について
  • 日々検索キーワードをチェックし手動で登録
    • ある程度効果はある
  • 同義かどうかが難しい場合がある
    • 「インゲン豆」「さやいんげん」など
• 0件ヒット対策
  • 0件のヒットとなっているキーワードのレシピを日々チェック
  • 新生ワードを早期発見するために日々リサーチ（twitterなど）
• 運用中気になったこと
  • 食材クエリとメニュークエリで離脱率が異なる
  • androidとiosでクエリが異なる
  • テレビの影響は大きい
  • 検索数が少ないキーワードへの対処優先度
• KPI
  • 最初は離脱率
  • その次、検索経由のCV
    • ただし検索した後、買い物に出かけるなど、タイムラグがあるため純粋なCVを測ることが難しい（検討中）

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

webpackの仕様を理解しないとたまにトラブルが起きるという話

GMOペイメントゲートウェイのトークン決済とは

ECサイトで決済処理を実装するときにGMOペイメントゲートウェイを活用する事になりました。
多様な決済方式に対応していて便利ですね。

GMOペイメントゲートウェイにはトークン決済という方式があります。
クレジットカード情報をJavaScript上でAPIに送信し、トークン化する事でセキュリティ的な観点で安心して決済処理を行う事ができる、というものですね。

実装

トークン化はコントローラを介さずJavaScriptで行います。
必要なライブラリはCDNで配布されています。
本番用と開発用があるのでお間違えの無いように

<!-- トークン決済開発用javascriptを読み込み -->
<%= javascript_include_tag 'https://stg.static.mul-pay.jp/ext/js/token.js' %>
※URLが変更されている場合があるので必ず最新のドキュメントを参照してください

Multipaymentが定義されるのでカード情報をsubmitする際に利用します。

Multipayment.getToken({ 
   パラメータ 
   }, 任意のコールバック関数); 

の形式です

公式ドキュメントのコードサンプルは以下の通り
最低限の機能なので、カード情報の入力に不足がある場合はアラートを表示して送信しない等の処理を挟むのをオススメします。

<script type="text/javascript"> 
  function execPurchase(response) { 
   if (response.resultCode != "000") { 
    window.alert("購入処理中にエラーが発生しました"); 
   } else { 
    // カード情報は念のため値を除去 
    document.getElementById("cardno").value = ""; 
    document.getElementById("expire_year").value = ""; 
    document.getElementById("expire_month").value = ""; 
    document.getElementById("securitycode").value = ""; 
    document.getElementById("tokennumber").value = ""; 
    // 予め購入フォームに用意した token フィールドに、値を設定 
    //発行されたトークンは、有効期限が経過するか、一度 API で利用されると、無効となります。 
    //複数のAPIでトークンを利用される場合は、tokenNumberにてトークンを複数発行してください。

    document.getElementById("token").value = response.tokenObject.token; 
    // スクリプトからフォームを submit 
    document.getElementById("purchaseForm").submit(); 
   } 
  } 

  function doPurchase() { 
   var cardno, expire, securitycode, holdername; 
   var cardno = document.getElementById("cardno").value; 
   var expire = 
   document.getElementById("expire_year").value + document.getElementById("expire_month").value; 
   var securitycode = document.getElementById("securitycode").value; 
   var holdername = document.getElementById("holdername").value; 
   var tokennumber = document.getElementById("tokennumber").value; 
   Multipayment.init("tshop00000001"); 
   Multipayment.getToken({ 
    cardno : cardno, 
    expire : expire, 
    securitycode : securitycode, 
    holdername : holdername, 
    tokennumber : tokennumber 
   }, execPurchase); 
  } 
</script> 

問題点

このサンプルでいうexecPurchaseにあたるコールバック処理は、
グローバルスコープに無いとCDNから取得したライブラリ側で認識されないのですが、

webpackがスコープを管理する都合でサンプルをこのまま記述してもexecPurchaseはundefinedになってしまいました。

解決策

window.execPurchase = execPurchase;

上記をスクリプトに追記し作成したコールバック関数をwindowオブジェクトに持たせることで解決しました。
package.jsonに設定を記載する等の手段がありそうでしたが上手くいかなかったのでこの手法に落ち着きました。

更なるトラブル

Uncaught ReferenceError: r is not defined

おっ解決したと思いきやデプロイしたら動かん…

何故ならwebpackはproduction環境では変数名等を変換して難読化させた状態でビルドするからです。

window.execPurchase = r;

Multipayment.getToken({ 
    cardno : cardno, 
    expire : expire, 
    securitycode : securitycode, 
    holdername : holdername, 
    tokennumber : tokennumber 
   }, r); 

上記のようにコールバック関数がr一文字に変換されていました
window.execPurchase = execPurchase;で宣言してもこれでは動かない…
今回の場合、幸いなことにコールバック関数は文字列を渡しても問題なく処理してくれるので

Multipayment.getToken({ 
    cardno : cardno, 
    expire : expire, 
    securitycode : securitycode, 
    holdername : holdername, 
    tokennumber : tokennumber 
   }, "execPurchase"); 

のようにコールバック処理を指定する引数を文字列にすることで解決できました。
変数名は勝手に変換されますが文字列はそのまま残ります。

普段意識しないですがwebpackはこういう変換処理をしてくれているんですね。
トラブルが起きない分には素晴らしいですがたまにこういう事が起きるという話でした。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

webpackの仕様を理解しないとたまにトラブルが起きるという話

GMOペイメントゲートウェイのトークン決済とは

ECサイトで決済処理を実装するときにGMOペイメントゲートウェイを活用する事になりました。
多様な決済方式に対応していて便利ですね。

GMOペイメントゲートウェイにはトークン決済という方式があります。
クレジットカード情報をJavaScript上でAPIに送信し、トークン化する事でセキュリティ的な観点で安心して決済処理を行う事ができる、というものですね。

実装

トークン化はコントローラを介さずJavaScriptで行います。
必要なライブラリはCDNで配布されています。
本番用と開発用があるのでお間違えの無いように

<!-- トークン決済開発用javascriptを読み込み -->
<%= javascript_include_tag 'https://stg.static.mul-pay.jp/ext/js/token.js' %>
※URLが変更されている場合があるので必ず最新のドキュメントを参照してください

Multipaymentが定義されるのでカード情報をsubmitする際に利用します。

Multipayment.getToken({ 
   パラメータ 
   }, 任意のコールバック関数); 

の形式です

公式ドキュメントのコードサンプルは以下の通り
最低限の機能なので、カード情報の入力に不足がある場合はアラートを表示して送信しない等の処理を挟むのをオススメします。

<script type="text/javascript"> 
  function execPurchase(response) { 
   if (response.resultCode != "000") { 
    window.alert("購入処理中にエラーが発生しました"); 
   } else { 
    // カード情報は念のため値を除去 
    document.getElementById("cardno").value = ""; 
    document.getElementById("expire_year").value = ""; 
    document.getElementById("expire_month").value = ""; 
    document.getElementById("securitycode").value = ""; 
    document.getElementById("tokennumber").value = ""; 
    // 予め購入フォームに用意した token フィールドに、値を設定 
    //発行されたトークンは、有効期限が経過するか、一度 API で利用されると、無効となります。 
    //複数のAPIでトークンを利用される場合は、tokenNumberにてトークンを複数発行してください。

    document.getElementById("token").value = response.tokenObject.token; 
    // スクリプトからフォームを submit 
    document.getElementById("purchaseForm").submit(); 
   } 
  } 

  function doPurchase() { 
   var cardno, expire, securitycode, holdername; 
   var cardno = document.getElementById("cardno").value; 
   var expire = 
   document.getElementById("expire_year").value + document.getElementById("expire_month").value; 
   var securitycode = document.getElementById("securitycode").value; 
   var holdername = document.getElementById("holdername").value; 
   var tokennumber = document.getElementById("tokennumber").value; 
   Multipayment.init("tshop00000001"); 
   Multipayment.getToken({ 
    cardno : cardno, 
    expire : expire, 
    securitycode : securitycode, 
    holdername : holdername, 
    tokennumber : tokennumber 
   }, execPurchase); 
  } 
</script> 

問題点

このサンプルでいうexecPurchaseにあたるコールバック処理は、
グローバルスコープに無いとCDNから取得したライブラリ側で認識されないのですが、

webpackがスコープを管理する都合でサンプルをこのまま記述してもexecPurchaseはundefinedになってしまいました。

解決策

window.execPurchase = execPurchase;

上記をスクリプトに追記し作成したコールバック関数をwindowオブジェクトに持たせることで解決しました。
package.jsonに設定を記載する等の手段がありそうでしたが上手くいかなかったのでこの手法に落ち着きました。

更なるトラブル

Uncaught ReferenceError: r is not defined

おっ解決したと思いきやデプロイしたら動かん…

何故ならwebpackはproduction環境では変数名等を変換して難読化させた状態でビルドするからです。

window.execPurchase = r;

Multipayment.getToken({ 
    cardno : cardno, 
    expire : expire, 
    securitycode : securitycode, 
    holdername : holdername, 
    tokennumber : tokennumber 
   }, r); 

上記のようにコールバック関数がr一文字に変換されていました
window.execPurchase = execPurchase;で宣言してもこれでは動かない…
今回の場合、幸いなことにコールバック関数は文字列を渡しても問題なく処理してくれるので

Multipayment.getToken({ 
    cardno : cardno, 
    expire : expire, 
    securitycode : securitycode, 
    holdername : holdername, 
    tokennumber : tokennumber 
   }, "execPurchase"); 

のようにコールバック処理を指定する引数を文字列にすることで解決できました。
変数名は勝手に変換されますが文字列はそのまま残ります。

普段意識しないですがwebpackはこういう変換処理をしてくれているんですね。
トラブルが起きない分には素晴らしいですがたまにこういう事が起きるという話でした。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Railsアプリケーションのバッチ処理を [whenever](https://github.com/javan/whenever) でスケジュール設定する際、デプロイ先のタイムゾーンの設定がUTCなんだけど、スケジュール設定は開発者にわかりやすく日本時間としたいケースがあったので、その対応方法について。

問題と背景

• デプロイ先のサーバのタイムゾーンの設定は UTC となっている（本当はJSTにしておいて欲しかったが、今更サーバの設定を変更したくない）
• ただし whenever のスケジュール設定(config/schedule.rb)は日本時間で記述したい
• whenever の schedule.rb ではタイムゾーンを指定することができず、システムで設定されているタイムゾーンを使用する。

対応方法

• schedule.rb で時刻設定時にタイムゾーンを変換する関数を用意。その関数使って任意のタイムゾーンからシステムのタイムゾーンに変更する

# config/schedule.rb

# Time クラスの拡張を利用するため ActiveSupport を require する
require 'active_support/core_ext/time'

# 時刻の文字列を日本時間で解釈して、システムのタイムゾーンに変換
def jst(time)
  Time.zone = 'Asia/Tokyo'
  Time.zone.parse(time).localtime($system_utc_offset)
end

# 日本時間の 午前 2:00 => UTC の 17:00 にバッチをスケジュール
every 1.day, at: jst('2:00 am') do
  runner 'HogeFugaBatch.execute'
end

参考

• https://github.com/javan/whenever/issues/481
• https://github.com/javan/whenever/pull/239

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

舎利子色不異空空不異色色即是空空即是色受想行識亦復如是 舎利子是諸法空相不生不滅不垢不浄不増不減

そもそも水平分割って何さ

同じ情報を複数のテーブルやデータベースに分けて分割する事です。
ユーザー情報が一つのデータベースに入っていたとしたら、

DB1
|ID|name|profile|
|1|イチ|弟達の世話で大変ですが愛おしいです|
|2|ニ|教授は美味しかったです|
|3|サン|お兄ちゃんに良く噛まれます|

DB1
|ID|name|profile|
|1|イチ|弟達の世話で大変ですが愛おしいです|
DB2
|ID|name|profile|
|2|ニ|教授は美味しかったです|
DB3
|ID|name|profile|
|3|サン|お兄ちゃんに良く噛まれます|

こんな風に複数のテーブルやデータベースに情報を分けて保存する事です。

どうして水平分割なんてやるのさ

データベースのレコード検索はインデックスを張る事で高速化が出来ますが、それでも数が莫大になってくると遅くなってきます。
それならば、保存する場所を複数に分ける事で1データベースのレコード数を絞り、その中で検索を掛ける事によって検索が遅くなる事を防ごうという訳です。

どうやって水平分割をするのさ

用途によって必ずしもそうではありませんが、基本的にテーブルの主キーであり、一意の数値であり、連番となるIDを元に保存/検索などをする対象先を判別するようにします。
ここでは、そのIDを元に水平分割をする場合の主に使われる2つの手法を紹介します。

範囲分割

IDを範囲分けして、対象先を判別します。
IDが1から100まではDB1に、
IDが101から200まではDB2に、
IDが201から300はDB3に、
そして301から400まではまたDB1に…という風に分割します。

DB1
|ID|name|profile|
|1|イチ|弟達の世話で大変ですが愛おしいです|
|2|ニ|教授は美味しかったです|
|3|サン|お兄ちゃんに良く噛まれます|
...
|100|ごますり|操られていただけなので勘違いしないで頂きたい|
|301|マンモス|何か話題になりました|
...

DB2
|ID|name|profile|
|101|目覚まし時計|友よ|
|102|サノスおばさん|燃え尽きたぜ…真っ白にな…|
|103|応援部隊その1|ソイヤッ！|
...

DB3
|ID|name|profile|
|201|王様|目覚まし時計が強過ぎて我が家を失いました|
|202|女王様|得意技は磔です|
|203|緊急脱出|ホールインワンしました|
...

剰余分割

IDをDB数で割った余りで対象先を判別します。DBが3つならば、
余りが0ならばDB1に、
余りが1ならばDB2に、
余りが2ならばDB3に、
分割します。

DB1
|ID|name|profile|
|1|イチ|弟達の世話で大変ですが愛おしいです|
...
|102|サノスおばさん|燃え尽きたぜ…真っ白にな…|
...
|201|王様|目覚まし時計が強過ぎて我が家を失いました|
...
DB2
|ID|name|profile|
|2|ニ|教授は美味しかったです|
...
|100|ごますり|操られていただけなので勘違いしないで頂きたい|
...
|103|応援部隊その1|ソイヤッ！|
...
|202|女王様|得意技は磔です|
...
|301|マンモス|何か話題になりました|
...
DB3
|ID|name|profile|
|3|サン|お兄ちゃんに良く噛まれます|
...
|101|目覚まし時計|友よ|
...
|203|緊急脱出|ホールインワンしました|
...

どっちが良いのさ

範囲分割と剰余分割、それぞれに利点欠点はあります。

範囲分割

利点:
対象先のデータベースを増やすといった時に設定の追加が簡単。
欠点:
設定を書くのが多少面倒。想定されるID数までの範囲を分割して、そしてそれを設定として全て書かなければいけない。
また、データの追加が大量に走った場合に処理が1つのデータベースに集中する。
ソーシャルゲームだと、ユーザー登録が沢山走った場合などには1データベースの性能がボトルネックとなる場合がある。

剰余分割

利点:
設定が簡単。IDを割った値で分割するだけ。
範囲分割での欠点のような、データの追加が大量に走る場合でも処理が複数のデータベースに分散されて一つに集中しない。
欠点:
対象先のデータベースを増やしづらい。また、増やしても設定が複雑になってしまう。
このIDまでは3で割った余りで対象先を判別し、このIDからは4で割った余りで分割する…とか、そんな事をしなくてはいけない。

まあ、一長一短ですね。
ただ、汎用性があるのは範囲分割の方だと思います。剰余分割の 対象先のデータベースを増やしづらい。また、増やしても設定が複雑になってしまう。 という事柄がかなり大きいので。他の手法であるハッシュ分割なども似たような形です。
そんな訳で、それぞれの利点欠点を理解した上で、プロジェクトに合った分割方法を選びましょう。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Sidekiq の Web コンソールが重いので Rails console からサクッとジョブのリトライとかしたい場合のメモ

キューの一覧を取得

 Sidekiq::Queue.all

キューに登録されているジョブの一覧を取得

 q = Sidekiq::Queue.new('キュー名')
 q.entries

ジョブが失敗した場合はリトライのキューに移る

リトライの一覧の確認〜ジョブの強制リトライ

 rs = Sidekiq::RetrySet.new
 rs.size
 rs.entries
 rs.entries[0].retry

リトライ待ちのジョブの削除

 rs.entries[0].delete

Dead (リトライ期限が過ぎたジョブ)

ds = Sidekiq::DeadSet.new
ds.size
ds.clear

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

開発環境として Docker を使っていると、開発者の環境固有の問題に対応するためにその環境固有の設定を追加したい場合がある。そのような場合のTips

背景

• ローカル開発環境を Docker で構築して開発者間の環境の差異をできるだけ少なくしている
• ただし、ホスト環境が Windows, Mac, Linux と様々で、個人毎に設定を微妙に変えたいケースがある

追記(2019/6/27)

どうも docker-compose はデフォルトで docker-compose.override.yml を読み込むようなので、以下のように環境変数の設定は不要だった。

• チームの docker-compose.yml をローカルでだけ上書きしたい – Qiita
• Share Compose configurations between files and projects | Docker Documentation

対応方法

• 環境変数 COMPOSE_FILE を使用するexport COMPOSE_FILE=docker-compose.yml:docker-compose.override.yml のように設定すると、 docker-compose.yml, docker-compose.override.yml 両方の設定がマージされる
  • docker-compose.override.yml は .gitignore でリポジトリ管理の対象外としておくことで、個人の設定をここに書くことができる。
  • 参考： Compose CLI environment variables | Docker Documentation
• いちいち export ... を打つのが面倒な場合、 direnv を導入すると良い
  • macOS で Homebrew 導入済みなら brew install direnv でインストールできる
  • 詳細は以下を参照
    • https://github.com/direnv/direnv

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

表題の件についてのメモ

背景

• Rails アプリケーションのローカル開発環境を Docker で構築
• その環境には Sidekiq の worker が稼働する、 worker コンテナ、Sidekiqがバックエンドとして使用している Redis が稼働している redis コンテナが存在する

現象

docker-compose によるコンテナの立ち上げ時、以下のエラーが発生して worker コンテナが落ちる

worker           | LOADING Redis is loading the dataset in memory
worker           | /app/vendor/bundle/ruby/2.5.0/gems/redis-4.0.3/lib/redis/client.rb:124:in `call'
worker           | /app/vendor/bundle/ruby/2.5.0/gems/redis-4.0.3/lib/redis/client.rb:107:in `block in connect'
(略)
worker           | /app/vendor/bundle/ruby/2.5.0/gems/redis-4.0.3/lib/redis.rb:278:in `info'
worker           | /app/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.2.3/lib/sidekiq.rb:113:in `block in redis_info'
worker           | /app/vendor/bundle/ruby/2.5.0/gems/sidekiq-5.2.3/lib/sidekiq.rb:95:in `block in redis'

原因

redisコンテナ起動時に --appendonly yes が指定されていた。

LOADING Redis is loading the dataset in memory というエラーは、 AOF(Append-only File)からデータをメモリ上に展開している間に更新(SET)などのコマンドを実行しようとした際に発生するらしい。

RDB/AOFファイルをローディングしている間、SETコマンドのようなものを実行すれば “(error)LOADING Redis is loading the dataset in memory”このようなエラーを出すが、infoコマンドは実行されます。 したがって、infoコマンドでローディング中なのか確認することができます。
REDIS INFO [section] コマンド

対処その１

Append-only File は、プロセスの予期しない終了等からデータを保護するための機構であるが、ローカル開発環境においてはそのような考慮は不要（消えても構わない）ので、 --amendonly yes オプションを取り除く。

   redis:
     image: redis:latest
     ports:
       - 6379:6379
     volumes:
       - redis:/data
-    command: redis-server --appendonly yes
+    command: redis-server

対処その２

あるいは、ローカルで保持しているRedis内の情報が消えても構わないのであれば一旦 redis コンテナに割り当てている Volume を削除してあげるという方法もある。

ただし、一時的なものなので AOF が肥大化するにつれていずれ問題が再発する。（と思われる）

ボリュームを削除する手順は以下（コンテナを停止している状態で実施する）

<ボリュームの一覧確認>
docker volume ls

<ボリューム削除>
docker volume rm xxxxxx_redis

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

API Gateway のエラー時のレスポンスのメッセージは必ずしもその原因と直結するような内容となっていないことが多々あり、原因の特定に時間がかかりがちなのでメモっておく。

※随時追加予定

※「レスポンス」の内容は、curl -vでのリクエストに対するレスポンスを多少加工して掲載している。

401 ‘Unauthorized’

レスポンス

< HTTP/2 401
< date: Wed, 22 May 2019 08:43:33 GMT
< content-type: application/json
< content-length: 26
< x-amzn-requestid: xxxxxxxxxxxxxxxx
< x-amzn-errortype: UnauthorizedException
< x-amz-apigw-id: xxxxxxxxxxxxxxxxxxx

{"message":"Unauthorized"}

原因

• カスタムオーソライザに必要な情報（特定のリクエストヘッダ等）がリクエストに含まれていない
  • 例えば Cookie のsession_idを使ってAPIへのアクセスを認可するオーソライザを設定している場合、Cookieヘッダがリクエストに含まれていない場合に前述のリクエストが返ってくる

403 ‘Missing Authentication Token’

レスポンス

< HTTP/2 403
< date: Wed, 22 May 2019 08:31:54 GMT
< content-type: application/json
< content-length: 42
< x-amzn-requestid: xxxxxxxxxxxxxxxxx
< x-amzn-errortype: MissingAuthenticationTokenException
< x-amz-apigw-id: xxxxxxxxxxxxxx

{"message":"Missing Authentication Token"}

原因

• API Gateway のエンドポイントのパスが間違っている
  • 例えば正しいエンドポイントのURLが以下であった場合
    • https://xxxxx.execute-api.ap-northeast-1.amazonaws.com/stage/api/v1/{+proxy}
  • 以下のように間違っている(/apiが抜けている)と前述のようなレスポンスが返ってくる
    • https://xxxxx.execute-api.ap-northeast-1.amazonaws.com/stage/v1/xxxxxx

403 Forbidden

(思い出したら書く)

403 ‘User is not authorized to access this resource with an explicit deny’

レスポンス

< HTTP/1.1 403 Forbidden
< Date: Wed, 22 May 2019 08:56:27 GMT
< Content-Type: application/json
< Content-Length: 82
< Connection: keep-alive
< x-amzn-RequestId: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
< x-amzn-ErrorType: AccessDeniedException
< x-amz-apigw-id: xxxxxxxxxxx

{"Message":"User is not authorized to access this resource with an explicit deny"}

原因

• カスタムオーソライザから DENY のポリシー文書が返却された場合に返ってくるレスポンス
  • カスタムオーソライザの呼び出し自体には成功しているので、大体のケースにおいては正常動作と言える（正常でない場合はカスタムオーソライザをデバッグすることになる）

503 (HTML形式で) ‘ERROR: The request could not be satisfied’

レスポンス

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>502 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>

原因

• オリジン(API Gateway)に対して http でアクセスしている
  • CloudFront のオリジンの設定(Origin Protocol Policy)が HTTP Only のようになっていないか確認する
  • API Gateway は HTTPS しかサポートしていないので、 HTTPS Only とするべき