コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

BigQueryではSELECT結果を他テーブルにInsert / テーブル洗い替えなどができる

知らない人は知らない機能。ちなみにこれはスケジュールドクエリでもできる。

やり方

クエリエディタの「クエリの設定」から表示されるウィンドウで設定できる。

f:id:shinkufencer:20200210084105p:plain

送信先で「クエリ結果の宛先テーブルを設定する」を選ぶと実行後にデータを扱う挙動が加わる

f:id:shinkufencer:20200210084128p:plain

  • 『空の場合に書き込む』は文字通り対象テーブルが空の場合のみ検索結果をINSERTする。
  • 『テーブルを追加する』の場合は結果をすべてINSERTする。
  • 『テーブルを上書きする』の場合は既存のテーブル情報をすべて捨てて、結果を入れ直す

なお、テーブルがない場合は作られるので事前に作る必要などはない。

参考リンク

BigQueryはスプレッドシートをテーブルとして読み込ませることができる

脆いテーブルなので、ご利用は計画的に。

やり方

データセットへのテーブル作成の際に「ドライブ」かつ「スプレッドシート」を選ぶと使うことができる。複数シートがあったり、先頭行からとりたくない場合は範囲指定をする。(下記の場合は TestReport シートの範囲をとっている、書式はスプレッドシートの範囲指定書式と同じ)

f:id:shinkufencer:20200210082831p:plain

また、各列の情報(フィールド)は自動抽出もできるが、名前をしっかり決めたい場合は自分で指定する。

f:id:shinkufencer:20200210082921p:plain

すべてを設定すると以下のようになる

f:id:shinkufencer:20200210082934p:plain

注意点

いくつかある

  • 元のスプレッドシートに列が加わるとSELECTがかけられなくなるので変更されないように気をつける
  • カラムにあたるフィールドは型が間違っているとSELECTできないので気をつける
  • 速度はイマイチなのでそこをどうにかしたい場合は別テーブルに書き出すほうがよい

参考

スプレッドシートにサクッとGoogleアナリティクスのレポートを出したいときには専用アドオンを使うと便利

知っている人は知っている、知らない人は知らないツール

ツールのリンク

ツール概要

GoogleAnalyticsのデータをスプレッドシートに出力してくれるアドオン、めんどうな処理などはこのアドオンに噛ませれば大体解決する

使い方

アドオンをインストールする

スプレッドシート上からアドオンをインストールする。

f:id:shinkufencer:20200209163452p:plain

f:id:shinkufencer:20200209163509p:plain

権限的にはかなり色々できるので許可したあとに無事インストールできると以下のような表示になる

f:id:shinkufencer:20200209163523p:plain

レポートの出力設定を作る

レポート対象のGoogleAnalyticsの設定を行う。基本的にはスプレッドシートを開いているアカウントと同じアカウントに紐付いているGAが処理の対象となる。Create new reportを選択

f:id:shinkufencer:20200209163544p:plain

いろいろな項目を設定できるのだが、今回は「日別」の「PV」をだす。以下のような設定になる。

f:id:shinkufencer:20200209163756p:plain

これで設定が終わると、設定を記述したシートが出来上がる

f:id:shinkufencer:20200209163912p:plain

レポートを実行する

右上の「アドオン」の中の「Google Analytics」「Run Reports」を押すと、設定シートを元にレポート作成が実行される

f:id:shinkufencer:20200209164147p:plain

レポートをスケジュールする

レポート作成はスケジュール実行もできる。実行時刻の一番細かい粒度は1時間なので、それで実行する。

f:id:shinkufencer:20200209164025p:plain

参考リンク

ナショナルクライアントという言葉の意味をざっくりまとめる

パナソニックのブランド名ではない。ということでざっくり。

出典

日本インタラクティブ広告協会が出している インターネット広告基礎用語集 という媒体の引用から

全国的な知名度やブランドを持つ大企業の俗称。4マス(テレビ・新聞・ラジオ・雑誌)に大きな広告予算を持つ企業を指すことが多い。 - ナショナルクライアント(ナショナルクライアント):インターネット広告基礎用語集:日経クロストレンド

ということで和製英語の様子

具体例

具体的にどんな企業?となるんですが、イメージとしては以下のような会社さんのようです。

最近ではキリンビール日産自動車KDDIといったナショナルクライアントによる成功事例も出てきている。 - ナショナルクライアントも注目 facebookの広告価値とは? | AdverTimes(アドタイ) by 宣伝会議

大概はマスメディア訴求をする会社≒ブランド訴求の広告を出すような会社というイメージでよさそう。

参考リンク

日本の祝日は内閣府が掌握してるので内閣府の情報を一次ソースとするのがよさそう

2020年限定の祝日移動について | 首相官邸ホームページ』の関連ネタ.

参照ページ

国民の祝日について - 内閣府

なぜ内閣府のページが良いか

祝日のシステム自体は『国民の祝日に関する法律』で定められているので、変更がある場合はこの法律に則って行われるが、「今年はどういうスケジュール?」のような情報は内閣府側で下記の用にアナウンスされているので、内閣府が伝えるページを見るのがよさそうである。

大臣官房総務課では、「国民の祝日」に関する事務を所掌しています。 - 国民の祝日について - 内閣府

ちゃんとこのページで過去の祝日のcsvなども配布しているし、振替の法令の情報や、振替の例まで乗っている。のっけ盛りページ。

参考リンク

enumの日本語化を実現するgem「enum_help」

ほう、こんなものが…という既存プロジェクトに入ってたgemをメモるシリーズ

出典

GitHub - zmbacker/enum_help: Help ActiveRecord::Enum feature to work fine with I18n and simple_form.

環境

rails (5.0.2)
enum_help (0.0.17)

効能

gemを入れたら config/locales/model/ にモデル名と同じymlを作り、フォーマットにしたがって記述すると {{モデル名}}.{{enumカラム名}}_i18n でlocaleに連動した文字列が帰ってくる

実例

Userモデルとして以下のような情報を定義する

class User < ApplicationRecord
  enum sex: { 
    male: 0, 
    female: 1 
  }
end

例えば config/locales/model/user.yml と作成する

ja:
  enums:
    user:
      sex:
        male: 男
        female: 女

と設定すると、以下のように _i18n をつけると日本語表記してくれる。

user.sex_i18n
#=> "男"

viewなどを作る際に便利

参考リンク

関連リンク

Backend For Frontend (BFF) についてざっくりまとめる

BFFでBest Friend Forever(ズッ友)のほうが出てきてしまうのでざっくりまとめ

意味

文字通りでフロントエンドのためのバックエンド機能のことを指す。

おそらくの呼称出典資料

SoundCloudにいたPhil Calçado氏が提唱したのが最初(の様子)

フロントエンドパターン(BFF)のバックエンド

Our original idea was to have different back-ends for different front-ends. The term BFF was coined by our Tech Lead for web, Nick Fisher (my initial suggestion was BEFFE, but our Dutch-speaking team mates vetoed that option).

Google和訳力を使うと以下のような意味

私達の原初のアイデアはフロントエンドごとに異なるバックエンドを用意することでした。BFFという用語は、WebのTech LeadであるNick Fisherによって造られました(私の最初の提案はBEFFEでしたが、オランダ語を話すチームの仲間はそのオプションを拒否しました)。

BFFの出来た経緯と役割

マイクロサービス化が進むと、モノリシックなアプリよりもでデータの拠り所が分散する。その結果、フロントエンド(Webページを描画するJSなどの機構や、スマートフォンアプリ)はそのデータを取りに行くために複数の場所にアクセスする必要が出てくる。そのため1画面を構成するために異様な量のAPIにアクセスする必要が出てくる。

この内容を回避するための方法として、フロントエンドのためのバックエンドという考えとしてBFFというアイデアができた。

BFFは複数のサービスのデータを束ねて管理することでフロントエンドで個々のデータを取得することを代行するバックエンドとシステムとして構成する。こうすることでフロントエンドがアクセスする対象のAPIは少なくなり、アクセスする先はグッと減らすことができた。

BFFのもたらすもの

メリット

  • フロントエンドが汎用的に用意されたAPI(Public Service API)から必要な情報を構成するための手間をバックエンドに委譲することができる
  • BFFはフロントエンドの都合で変更できるので、依存の広がりをそこで抑制することができる
    • BFFが下位互換性を維持できれば、それより後ろのサービス群のバージョン変更への依存性は薄くすることができる

デメリット

  • BFFごとに重複したロジックが作られがち
    • ただコンテキスト含めて本当に同じロジックであれば別途サービスを作り出せばいい
  • フロントエンドの複雑性をバックエンドに移しただけではあるので、バックエンドに移したことで複雑性が解決するわけではないのでそこに向き合う必要はある

関連リンク