読者です 読者をやめる 読者になる 読者になる

production.log

ピクスタ株式会社でエンジニアのリーダーをやっている星直史のブログです。

Re:dashのインストールから定期実行までの手順と使用感のまとめ

Re:dash その他 インフラ周り

前回までの記事で

と、Webサービスのデータ解析をする上で必要なデータソースから取り込む手順を書きました。
今回は、それを定期的に実行する設定の手順を書きます。

Re:dashの設定

  1. クエリ画面にアクセス
  2. Refresh Scheduleのリンクを押下
  3. 実行スケジュールを設定。 上記の設定で決まった時間、決まった間隔で実行することが可能です。

また、Re:dashはクエリで取得するデータはページにアクセスする度に取得するわけではなく、内部に保存することで高速に情報を取得するようになっています。
取得するのに時間がかかるクエリは、深夜に実行しておくのが賢い使い方かもしれません。

f:id:watasihasitujidesu:20160815165803p:plain

Googleスプレッドシートの設定

  1. メニュバー > アドオン > Google Analytics > Schedule reportsを押下
  2. Enable reports to run automatically. にチェック
  3. 実行する間隔と時間を設定

f:id:watasihasitujidesu:20160815165828p:plain

f:id:watasihasitujidesu:20160815165842p:plain

以上で定期実行の設定は終わりです。
GoogleスプレッドシートとRe:dashの設定は、多少互いの実行時間を気にする必要はありますが、
ここまでできれば、自動でデータが取得できるので、Re:dashでダッシュボードを設定したり、
良い感じにグラフを組み合わせることで、データ可視化 & 共有プラットフォームの構築が可能になります。

まとめ

個人的には、
これまでRailsActiveRecordでデータ取得して〜
Viewでhtml書いて〜
Google Chartsでグラフ描画して〜
あ、そうだそうだ、絞り込みも追加して〜

と、自分でゴリゴリ書いていくのではなく、閲覧系の機能はRe:dashにお任せして、
更新系機能やRe:dashで実現しきれない部分だけは自分で作っていた方が良いと思いました。

また、難しいと感じる点は2点あります。

1点目は
GoogleスプレッドシートSQLの出力イメージをRe:dashで使えるように考えるは難しいのではないかと感じています。
特に、非エンジニアに運用を展開するときは、そこを厚めにサポートしなければ組織根付いていかないのかなと思っています。

2点目は
ダッシュボードに属させるクエリの管理です。
ここのカテゴライズを考えておかなければ、結局「あのデータどこに行ったっけ?エンジニアに聞いたろ」
ということが発生してしまうので、エンジニアの手間があまり軽減しない可能性があると思いました。

Re:dashがここまでデータ抽出 => 可視化を簡単に出来るとは思いませんでした。
難しいと感じる点で書いた2点、すなわち組織への展開と運用方法の確立さえうまくいけば、
エンジニアやディレクターの工数軽減できるサービスだと思います。

GoogleAnalyticsからGoogleスプレッドシートに自動でデータを取得する

Re:dash

前回の記事では、Googleスプレッドシートの値をRe:dashに取り込む方法を紹介しました。 今回は、GoogleAnalyticsのデータをGoogleスプレッドシートに取り込む手順を紹介しようと思います。

1. Googleスプレッドシートのアドオンを取得する。 GoogleスプレッドシートのアドオンにGoogleAnalyticsががあるので、それを取得します。 f:id:watasihasitujidesu:20160815123805p:plain f:id:watasihasitujidesu:20160815123833p:plain

2. メニューバー > アドオン > GoogleAnalytics > Create new reportで取得情報を設定する

Create new reportを選択すると右側に情報入力欄が表示されます。 そこの、 1) Name Your Report(これは好きな名前でOK) 2) Select Account Information - Account - Property - View (Profile) を設定してください。 上記の設定は、情報取得元になります。

入力が完了したらCreate Reportボタンを押下します。 f:id:watasihasitujidesu:20160815123904p:plain f:id:watasihasitujidesu:20160815123915p:plain

3. 取得したい情報を入力する。 2の手順が完了するとReport Configurationというシートが追加されます。 そのシートの下記項目を埋めていきます。

  • Metrics(縦軸)
  • Dimensions(横軸)

今回は、下記の内容を記入して実行してみます。

項目名 入力値
Metrics ga:sessions
Dimensions ga:date,ga:medium
Sort -ga:sessions

上記は直近7日間を日ごとに、参照元別のセッション数を出すための切り口を設定しています。

4. 実行する メニューバー > アドオン > GoogleAnalytics > Run reportsで値を取得します。

f:id:watasihasitujidesu:20160815123937p:plain

取得した値を元にRe:dashに適用できるようにピボットテーブルなどで加工すると、Google AnalyticsのデータをRe:dashで表示できるようになります。

Googleスプレッドシートの値をRe:dashに取り込む

Re:dash その他 インフラ周り

Re:dashではDataSourceにGoogleスプレッドシートを指定することができます。 Googleスプレッドシートからデータを取り込む場合、 GoogleAPIConsoleからAPI Keyを発行するなど、手順が多かったので、今回の記事でまとめようと思います。

1. GoogleAPIConsoleにアクセス

2. 新規プロジェクト作成 Re:dash用のプロジェクトを作成します。 f:id:watasihasitujidesu:20160814130146p:plain

3. API Keyを作成

  • 画面左のサイドナビより認証情報をクリック f:id:watasihasitujidesu:20160814130147p:plain

  • 認証情報を作成 > サービス アカウントキーを選択 f:id:watasihasitujidesu:20160814130145p:plain

  • サービスアカウント種別を新しいサービスアカウントを選択し、各項目を入力。キーのタイプはJSONを選択 f:id:watasihasitujidesu:20160814130148p:plain

  • 画面左のサイドナビよりダッシュボードをクリック > APIを有効にするをクリック f:id:watasihasitujidesu:20160814130142p:plain

  • 検索フォームに"Drive"と入力すると出てくるGoogle Drive APIを選択 f:id:watasihasitujidesu:20160814130143p:plain

  • 有効にする をクリック f:id:watasihasitujidesu:20160814130144p:plain

これで、Googleスプレッドシートを操作するAPIキーの取得と、APIの有効化が終わりました。

4. Googleスプレッドシートで、APIと連携

  • API Keyを作成する過程で、秘密鍵jsonとしてDLできたはずです。このjsonファイルにemailが記載されているので、それをコピーしておきます。 
  • Googleスプレッドシートの共有設定で、先ほどコピーしたemailと共有する。

f:id:watasihasitujidesu:20160814131317p:plain

5. Re:dashでDataSourceを追加 Re:dash側でデータソースを追加します。
typeはGoogleSpreadSheetを選択し、API Keyを取得する際にDLしてきたjsonをファイル選択して、作成します。

f:id:watasihasitujidesu:20160814131333p:plain

6. クエリ作成 クエリ作成は少し、注意する必要があります。
取り込みたいGoogleスプレッドシートのURLが
https://docs.google.com/spreadsheets/d/10fdasFMDSjige4dfsaOMGF0asfmm1/edit#gid=2008635114
というURLで、左から2番目のシートを取り込みたい場合のクエリは

10fdasFMDSjige4dfsaOMGF0asfmm1|1
となります。
注意することは2つあります。
1. スプレッドシートのURLとシートの番号は|で区切る
2. シートの番号は左から0,1,2...となる。
10fdasFMDSjige4dfsaOMGF0asfmm1|1

f:id:watasihasitujidesu:20160814132025p:plain

この方法を参考に、自身のクエリを作り、実行すると、GoogleスプレッドシートのデータをRe:dashに取り込むことができます

Re:dashでデータソースとしてMysqlを追加する

AWS その他 インフラ周り Re:dash

saitou.hatenablog.com 前回の記事でRe:dashを使えるようにしましたので、今回はDataSourceとしてMySQLを追加してみます。

1. ログインする 初期ユーザーのログインidとpassは下記の通りです。 ID: admin PASS: admin

2. 画面右上のDBマークをクリックする

f:id:watasihasitujidesu:20160814123142p:plain

3. New DataSourceをクリック

f:id:watasihasitujidesu:20160814123151p:plain

4. 項目を埋めていく

f:id:watasihasitujidesu:20160814123204p:plain

5. DBが作成されたことを確認

f:id:watasihasitujidesu:20160814123155p:plain

6. クエリを実行してみる http://作成したインスタンスのIP/queries/new 上記にアクセスし、DataSourceを作成したDBを選択すると、 画面左側にスキーマ情報が表示されました。 スキーマが表示されれば接続自体できていますので、クエリを作成-実行してみてください。

f:id:watasihasitujidesu:20160814123206p:plain

Re:dashはスキーマを確認できるだけではなく、クエリの整形や、 グラフのpngダウンロード, 数値のCSV, Excelダウンロードまでサポートしています。

また、作成したグラフは範囲を指定することで、特定の日付に絞り込んだりすることができるので、 いちから自分で画面を作るより、だいぶ楽です。

データ可視化, 共有プラットフォームとして人気のRe:dashをAWS EC2で試してみるまでの手順

AWS DB その他 インフラ周り Re:dash

うちの会社では

ということが数多くあります。

正直Railsで実装するとなると、viewまで書かなければならなくしんどいのと、 GAからデータ取得し、スプレッドシートに貼り付けという作業をdailyでやり続けるめんどくささがありました。

これらの作業を自動で取得からグラフ作成できる良いツールはないかと探していたところ、 Re:dashと言われるデータ可視化, 共有プラットフォームツールがあるということで、試してみました。

今回はAWS EC2を使用してログインするところまでの手順を書こうと思います。

Re:dashとは

Re:dashとは、DataSource*1*2にクエリを投げ、返って来た結果を簡単にグラフ化、共有、ダッシュボードに登録することで、
データ可視化や共有プラットフォームとして機能することが期待できるツールです。 また、クエリは定期実行*3させたり、クエリをForkして使いまわせたりできます。 データやグラフについても、CSV, ExcelでDLや、iframeでhtmlに組み込み、png画像としてDLできたりします。

f:id:watasihasitujidesu:20160814120841p:plain

AWS EC2で試す手順

  1. AMIを使用する。 AWSで試すのであれば、AMIを使用するのが、最速です。 リージョンが東京*4であればami-b30ec9d2というAMIIDですぐに環境を立ち上げることができます。

f:id:watasihasitujidesu:20160814120845p:plain

  1. セキュリティグループの設定 Re:dashの操作方法は2種類あります。
  2. Webからアクセスして操作する方法
  3. ssh接続して操作する方法

なので、セキュリティグループで22(ssh), 80(http), 443(https)を開けておく必要があります。 また、AMIのOSはubuntuですので、ssh接続する際のユーザーはubuntuを指定する必要があります*5
ssh -i ~/.ssh/public.key ubuntu@ip-adress

  1. ログインしてみる
  2. で作成したインスタンスのIPにアクセスしてみましょう。
    アクセスするとIDとPASSを入力するフォームがあるので、
    初期ユーザの
    ID: admin
    PASS: admin
    でログインできるはずです。

AWS EC2のAMIを使用すれば、少しの時間でRe:dashを使えるようになります。
AWS以外にも

  • Google Compute Engine
  • Docker Compose
  • Heroku
  • apt-get などサポートしているので、初期導入までは比較的容易に済みそうです。

*1:MySQL, PostgreSQL, TDなど

*2:Google SpreadSheetも含まれるのでDataSourceと表記しました

*3:毎分, 時, 週, 月など

*4:ap-northeast-1

*5:普段ubuntuを触らないので、ssh接続するのに小一時間くらいハマりました

オーディオブックをオススメできない理由を挙げていきます

その他

背景

通勤時間を有効に使う為に、オーディオブックを何冊か購入したのですが、 予想以上に使い勝手が悪かったので、お勧めできない理由を挙げていきます。

オーディオブックとは?

オーディオブックとは、本の内容を朗読した音声データです。 オーディオブックをiTunesなどで再生して、移動時間などのすきま時間に 耳から情報を入れることができる代物です。

オーディオブックを買った目的

通勤時間に少しでも学びを取り入れたかったので、買ってみました。 電車内、バス内で本を広げたくない(られない)、けど、本を読みたい! というニーズを満たしたかったため、購入しました。

何がダメだったか?

自分に合わなかったポイントを列挙すると下記の通りです。

  • 途中から再生する際、どこまで聴いたかわからない
  • 本を読み返したい時に素早くアクセスできない
  • 聴覚からでしか情報を得られないため、記憶が定着しない

途中から再生する際、どこまで聴いたかわからない

オーディオブックは音データのため、本厚みはもちろん、目次などがないため、 どこまで聴いたか覚えていなければなりません。 自分の場合、移動時間にオーディブックを聴くことが多いのですが、移動時間は10分であったり、20分、30分であったりまちまちです。

移動が終わる度にどこまで聴いたか再生時間を記憶するのは面倒で、結局2重で聴く場合や、 時間をかけて聴いたところまで再生と停止を繰り返すことが多くなってしまい、だいぶストレスでした。

本を読み返したい時に素早くアクセスできない

本の中には一度読んではい終わり〜ってだけではなく、 何度も読み返したくなる時があると思います。

自分の場合、書籍で読むと、どこに何が書いてあるかを、 本の厚みと、本を見開いた時の左右どちらかのページに書いてあったか?を だいたい記憶しているため、一度読めば、次回以降は素早くアクセスできます。

しかし、オーディオブックになるとそうはいかず、 聴いた情報は総再生時間のどこに位置するのか?という情報しかなく、 また、その時間を視認する術がないので、2回目以降のアクセスにとんでもなく時間がかかってしまいます。

聴覚しか情報を得られないため、記憶が定着しない

オーディブックのサイトでは耳から学ぶことで効果的に記憶に定着とお勧めされていましたが、 自分はそんなことありませんでした。

さきほど、書きましたが、自分は、 本の厚みと、本を見開いた時の左右どちらかのページに書いてあったか?を記憶していきます。 まだオーディオブックに慣れていないのかもしれませんが、基本的に移動中に聞き流しているだけなので、記憶する努力をあまりしておらず、 内容が、記憶にまったく定着しませんでした。

耳から学ぶことで効果的に記憶に定着できるのは、 書籍とオーディオブックの両方を購入し、聴きながら書籍を読むことで記憶に定着しやすくなるのではないかと思いますが、 同じ内容のものを二重で購入しなければなりませんし、 朗読を聞き取るスピード < 読むスピードの場合、処理能力の差でストレスを感じてしまいます。

自分は3つのオーディオブックを購入したのですが、 うち2つは何度も読み返したいと思い、結局書籍を購入しました。

さらに、自分の場合は、完全に朗読を聞き取るスピード < 読むスピード であったため、オーディオブックを聴くことはなくなりました。

まとめ

何度も読み返す必要がないような本(小説とか?)*1であり、 かつ、記憶に定着させる必要がない本であれば、オーディオブックを買っても良いのではないでしょうか。

ハウツー本、内容に頭を使う本、記憶に残しておく要素が少しでもある本においては、 オーディオブックはまったくお勧めできません。

ちなみにAmazonでも一部の書籍はオーディブックで販売開始されているようです。

*1:そんな本があるかわわかりませんが

エンジニア版 人を動かすだと感じた TeamGeekを読みました。

書評

最近はコードより人とやりとりすることが多くなってきたので、TeadmGeekを読んでみました。
今回はその感想を書きたいと思います。

エンジニアが他人とうまくやっていく知見が詰まった本

TeadmGeekは、チームで仕事をするプログラマーに向けた本です。
また、他人とうまく仕事をするということにフォーカスを当てているので、プログラムの話は一切出てきません。

この本は6章立てです。

  • ソフトウェア開発はチームスポーツである
  • チームの文化を作る効用
  • リーダーの必要性
  • 良くない振る舞い(行動的な意味)を排除する方法
  • 開発チームが属する組織に対しての操作技法

一人のエンジニアとしての心構えとして有名な3本柱、HRT(謙虚、尊敬、信頼)の重要性や、
チーム文化の重要性、組織に対しての行動の仕方などが書いています。

HRT(謙虚、尊敬、信頼)

チームで開発を進めていくと衝突する、あらゆる人間関係は、謙虚、尊敬、信頼の欠如により、発生するものだと書かれています。
謙虚、尊敬、信頼とだけ聞くと、自らの意見を殺た方がよいのか?と思ったのですが、そういうことではなく、
チームとしてよりよい成果を得るための効率的なコミニュケーション方法だと学ぶことができます。

本のなかでは、実際の事例を基に、テクニックを活かすとこうなる!というような構成で書かれています。

この本を読んだ後に思ったのは、
HRTを知らない人(例えば超絶自分勝手な人)に対峙した場合に、一歩引いた視点で接することができるのではないかと思いました。
本書の狙い通り、なるべく衝突を回避すべく、落ち着いて誠実に対応できるでしょう。

チームには文化が必要

開発チームが共有する文化(経験・価値・目標)は、効率的なコミニュケーションや、エンジニアリングに必要ということはなんとなくわかっていて、本にも書いていたのですが、
発見があった点は、新しく入ってきたメンバーに対しての抵抗力にもなるというところでした。

文化がないチームに新しくメンバーが入ってきた場合、入ってきたばかりのメンバーの声が強ければ、
一瞬にしてその人価値観が文化になってしまう恐れがあると書かれていました。

発足してから時間が経ったチームには、文化を明文化する必要性が見えてきたのは良かったです。

チームにはリーダーが必要

この本では、リーダーに"なってしまった"人のための行動のコツについても書いてあります。 具体的には下記のことが書かれています。

  • 初期の心理状態
  • 陥りやすい悩み
  • 心構え
  • エンジニアとリーダーは仕事が違うこと
  • 行動のアンチパターン
  • 良い行動パターン

リーダーは、チームの触媒になるよう、目標を掲げたり、メンバーやチームの成功と幸せを考えたりと、
コードを書いていた時とは違う時間の使い方をしなければならないと、この本でも書いていました。

マネージャー向けに書かれた本でも書かれていたのは、以前のエントリでも学びましたが、
エンジニア向けに書かれたこの本でも同様のことが書かれていたので、妙な納得感がありました。

良くない振る舞い(行動的な意味)を排除する方法

リーダーからもう一歩上の視点になったことについても書かれていました。
良くない振る舞い(行動的な意味)を排除する方法*1と、
開発チームが属している組織に対しての行動についてです。

基本的には、HRTの精神で臨むことを前提として書かれています。
良くない振る舞いに対しては、相手の想いと伝え方を最大限考え、対処するのがベストプラクティスだと学べます。
また、良くない振る舞いをしている人であったとしても、基本的には自分の中での正義があるので、
そのベクトルを揃えるために、チームの文化も必要だと感じました。

組織に対しての行動

エンジニアは、より良いコードを書くことばかりに集中していてはダメだと書いています。
組織でうまく働くことについても書かれています。

本を読んで感じたのは、入社した瞬間の信頼貯金0の状態から、組織に信頼され、自分の意見や運命をコントロールできるポジションにつくまでの行動について書かれていると思いました。

エンジニアとしては、リリースよりもリファクタリングや技術的な解決に目が行きがちだが、
組織としては、サービスのローンチやユーザーに与えるインパクトの方が圧倒的に価値があることを、認めるべきと書かれています。

エンジニアは開発するだけが全てではなく、客観的(会社やビジネス側から見る視点)に見た事実を理解した上で、技術を活かすアプローチではないと、苦しくなると、だいぶ生々しいことが書かれています。

まとめ

この本はエンジニア版の人を動かす*2だと思いました。
HRTを基本原則として、チームで成果を出すための知見が詰まった本なので、ほぼ全てのエンジニアにお勧めできる本だと思います。

また、リーダーとしての視点や、エンジニア個人として組織内での動き方についても書かれているので、"チームで成果を出す"という点以外でも十分学びを得られる本だと思います。

*1:本の中では有害な人の追い出し方と書いていますが、有害な人=特定の個人と勘違いしやすいので、良くない振る舞い(行動的な意味)を排除する方法としています。

*2:D・カーネギー