re:dashでよく使われているクエリーを調べる
re:dashのFork機能はすごく好きなんだけど、便利すぎて気軽にForkされる結果、使ってるのか使ってないのかわからないクエリーが増えてしまいがち。
この記事をみたら統計情報っぽいのが取れるようなので、ちょっといじって以下のようにした。
使用しているバージョンは 0.10.1+b1836。
SELECT object_id AS query_id, SUM(CASE WHEN action = 'view' THEN 1 ELSE 0 END) AS view, SUM(CASE WHEN action = 'execute' THEN 1 ELSE 0 END) AS execute FROM events WHERE object_type = 'query' AND object_id != '' AND created_at BETWEEN to_date('2016-11-01', 'YYYY-MM-DD') AND to_date('2016-11-17', 'YYYY-MM-DD') GROUP BY object_id ORDER BY execute DESC;
結果はこんな感じ。
object_id | view | execute -----------+------+--------- 78 | 125 | 99 68 | 123 | 106 87 | 68 | 66 79 | 68 | 55 85 | 68 | 42 103 | 63 | 50 107 | 59 | 43 8 | 58 | 13 89 | 53 | 7 125 | 52 | 28 109 | 48 | 21 104 | 44 | 11 112 | 39 | 21 100 | 39 | 19 115 | 31 | 2 122 | 25 | 9
この結果をみて、使用頻度の低いクエリーは積極的にアーカイブすることができそう。
おまけ
events テーブルはこんな感じ。
テーブル "public.events"
列 | 型 | 修飾語
-----------------------+--------------------------+-----------------------------------------------------
id | integer | not null default nextval('events_id_seq'::regclass)
org_id | integer | not null
user_id | integer |
action | character varying(255) | not null
object_type | character varying(255) | not null
object_id | character varying(255) |
additional_properties | text |
created_at | timestamp with time zone | not null
インデックス:
"events_pkey" PRIMARY KEY, btree (id)
"events_org_id" btree (org_id)
"events_user_id" btree (user_id)
外部キー制約:
"events_org_id_fkey" FOREIGN KEY (org_id) REFERENCES organizations(id)
"events_user_id_fkey" FOREIGN KEY (user_id) REFERENCES users(id)
action, object_typeにはこんな値が入っていた。
action
add_data_source add_member api_get archive autorefresh cancel_execute change_data_source_permission create delete edit edit_description edit_name execute execute_query fork login pivot remove_data_source remove_member search update update_data_source view view_source
object_type
dashboard data_source datasource group group_data_sources page query redash user visualization widget
プロダクトマネージャーカンファレンスに参加しました
10/24,25の両日開催されたプロダクトマネージャーカンファレンスに参加してきました。
参加を直前で決めたこともあり、たびたび帰社して打ち合わせを済ませてから会場に戻ったりしていたので、Pokemon GOをやっていればたまご2つぐらい孵せたと思います（電池がなくなると困るので控えました
なぜ参加したのか
私の職種は肩書上「ソフトウェアエンジニア」なのですが、今の仕事をしてからずっと一つのプロダクトに関わっています。
物言いたがりな性格もあって、これまでもプロダクトの方向性について議論するのが好きだったのですが、最近になってプロダクトマネージャー的な役割も担うことになったため、まずはインプットを増やしたいなという気持ちで参加しました。
もちろんプロダクトマネージャーという役割については興味があって、興味をもったきっかけはRebuild.fmのこのエピソードあたりだったと思います。通勤長いしまた聴き返そうかな。
セッションの感想
いろいろな方が記事を書かれていますし、Togatterにもまとまっているので、内容についてはそちらを読んでいただくのがよいと思います。
そのうち発表資料をまとめて公開されるような話もされていたような気がします。
個人的にはfreeeの佐々木さん、クックパッドの池田さん、Increments 及川さんとNiantic 河合さんのセッションは特に共感するところが多かったような気がします。
及川さんと河合さんのセッションについては、終了後のAsk the speakerコーナーが大行列になったことを受けて、ランチタイムを返上してのセッション延長というのが胸熱な展開で、柔軟な対応が本当に嬉しかったし、いいランチタイムになりました。その場の熱量をうまく力に変えていくのがPMの本懐なのかなーと、運営のみなさまからも感じるものがありました。
他にもTwitterを眺めていると聞きたかったな。。と思うようなセッションが多かったのですが、そういうタイミングに見事なまでに打ち合わせがぶつかっていたので、あとで資料を読み返したいなと思っています。
セッション中の撮影について
このカンファレンスはセッション中の撮影について明確にルールが提示されていました。ここまでいい意味で徹底的にやるのは初めてだったかもしれません。
カメラのシャッター音は本当に耳障りですし、話している側も聞いている側も気分がいいものではないので、セッションに集中するためにもそういった取り組みをされていたのかなと思います。
（それなのにシャッター音が時折聞こえたのは、しっかりとルールを守る方が多かっただけに残念でした。。
アンカンファレンス
せっかく参加したんだし、なんか話してみたいなと思って、1日目の帰りがけにアンカンファレンスに応募してみました。
貼っておいた。字が汚い。 #pmconfjp pic.twitter.com/uieJHt21Fs
— Takuya Arita (@ariarijp) 2016年10月24日
発表では、ここ最近の体験や、これからどうしようかなーと考えていたことをただただお話した感じになります。あとからスライド読んでも全然伝わらないですね。。
かなりの釣りタイトルで申し訳ないなーと思いながらも、集まっていただいた皆様には本当に感謝しています。すごくうれしかったです。
並びを見て、最悪の場合は会場の空気に向かって話すシミュレーションしてる https://t.co/JPXqSEdkzc
— Takuya Arita (@ariarijp) 2016年10月25日
#pmconfjp のアンカンファレンスで発表しました。読み返す価値はあんまりないけど、記録としてアップロードしておく。 / 使われない機能 https://t.co/GkVyGftVfa
— Takuya Arita (@ariarijp) 2016年10月25日
発表のあとは他のブースをまわってみたりしていたのですが、ペパボのいのうえさんの発表が特によかった。
いいフィードバックを受けるための仕組みを作るというような内容で、すでにご本人による記事も公開されていたので、スライドは貼らずに記事のリンクだけ貼っておきます。
Networking Party
ぼっちを避けるためという目的もあってアンカンファレンスで発表した結果、多くの方に声をかけていただきました。
アンカンファレンスでお話した、使われなくなった機能とどうやって付き合っていくか？というような実践的な話もしつつ、プロダクトという共通の関心事について初対面の方といろいろ議論できたおかげでとても有意義な時間を過ごせました。
いろんな方に話しかけていただいて、アンカンファレンスで発表してよかったー！という気持ちになりつつ会場をあとにします #pmconfjp
— Takuya Arita (@ariarijp) 2016年10月25日
まとめ
もちろん参加前から期待はしていたのですが、期待通りに濃い内容のカンファレンスだったなと改めて思います。
各社のPMがまったく違ったプロダクトに関わりながらも、共通の価値観を持っていたり、プロダクトやチームの特性にあわせた独自の判断基準があったりするなかで、
それをある意味「ぶつけ合う」ような2日間だったと思います。
運営のみなさま、登壇者のみなさま、私の発表を聞いてくださったり、懇親会で声をかけていただいたみなさま。ありがとうございました！
SpecinfraでリモートホストのOS情報を知る
使ってみようと思ったきっかけ
とある事情で社内で使用している数多のサーバーのOS情報をまとめたりしたくなったのでSpecinfraについて調べました。
使い方を調べる
検索しても参考になりそうな記事は少なく、この記事を参考にして書き始めました。
が、追記に内容が古いと書かれているとおり、このままでは動作しませんでした。
なんとか動かすことができた
Specinfraのコードを読みつつ、サンプルコードを読みつつ修正をしていたら、参考にしていた記事とは全く別物になりましたが、なんとか動かすことができました。
モジュール名がSpecInfraからSpecinfraに変わっていることに気づかなかったのが最大のハマりポイントだった気がします。
参考にしたコードの一部
specinfra/multiple_backends.rb at master · mizzy/specinfra · GitHub
specinfra/specinfra.rb at master · mizzy/specinfra · GitHub
specinfra/base.rb at master · mizzy/specinfra · GitHub
specinfra/ssh.rb at master · mizzy/specinfra · GitHub
サンプルコード
Vagrantっぽい接続情報になっていますが、ホストなどは適宜書き換えていただければリモートホストでも動作すると思います。
SSHの接続情報まわりはNet::SSHで使えるものが、そのまま使えるようです。
require 'specinfra'
ssh_options = {
host_name: 'localhost',
user: 'vagrant',
port: 2222,
keys: ['~/.ssh/id_rsa'],
}
backend = Specinfra::Backend::Ssh.new(
host: ssh_options[:host_name],
ssh_options: ssh_options,
disable_sudo: true,
)
p backend.os_info
実行してみる
Bundlerを使ったので bundle exec で実行します。
$ bundle exec ruby os_info.rb
{:family=>"ubuntu", :release=>"14.04", :arch=>"x86_64"}
感想
諸事情によりサーバーの環境がバラバラだったりするので、こういった方法で自動的にサーバーの情報を集めることができれば、辛い台帳管理などしなくてもよくなりそうだなと思って試してみました。
思ったほどハマらずに動作確認できたので、さっそく実践投入するつもりです。
Qiita/Qiita:teamの記事をJSON Lines形式で取得するqiitadumpを作った
最近ははてなブログに引っ越したのでQiitaをあまり使わなくなってしまったけど、過去に書いた記事や、社内で利用しているQiita:teamの記事をElasticsearchに入れて遊んだりするときに便利そうだと思ったので作ってみました。
使い方
準備
Qiitaのアクセストークンが必要なので、このあたりを参考に。権限は read_qiita と read_qiita_team があればいいでしょう。
インストール
$ go get -u github.com/ariarijp/qiitadump
実行
アクセストークンを指定して以下のように実行します。
$ qiitadump -token YOUR_ACCESS_TOKEN > dump.json
デフォルトでは20件取得しますが、 -limit オプションで件数を変更できます。
Qiita:teamの記事を取得する場合は以下のように -host を指定して実行します。
$ qiitadump -token YOUR_ACCESS_TOKEN -host teamname.qiita.com > dump.json
出力されるJSONの形式はQiitaのAPIドキュメントのとおりです。
この他にもいくつかオプションがありますが、詳しくはREADMEをご覧ください。
SQL書き方ドリルのサンプルDBをre:dashで遊べるようにするVagrantfile
最近は社内でSQLの啓蒙活動をしています。
幸いにも何人か興味を持ってもらったので、一通りSQLを学べそうな「SQL書き方ドリル」を会社で買ってもらったので、 SQLとあわせて啓蒙中のre:dashから、書籍付属のサンプルDBを使って、手を動かしながら勉強できるような環境を作ってみました。
改訂第3版 すらすらと手が動くようになる SQL書き方ドリル (WEB+DB PRESS plus)
- 作者: 羽生章洋,和田省二,菅井大輔
- 出版社/メーカー: 技術評論社
- 発売日: 2016/04/12
- メディア: 大型本
- この商品を含むブログを見る
前提
お使いの環境でVagrantが使えるようになっている環境を前提とします。
Macで動作確認していますが、Windows, Linuxでも動くと思います。
準備
re:dashをGitHubからcloneします。
$ git clone https://github.com/getredash/redash.git $ cd redash
次に、Vagrantfileを以下のように書き換えます
MySQLのrootユーザーがパスワードなしであったり、redashユーザーのパスワードが雑だったりしますが、ローカル環境での利用を想定しているためご了承ください。
最後に、SQL書き方ドリルのCD-ROMのデータをVagrantfileと同じ階層にSQL_DRILLという名前のディレクトリを作成し、その中に入れておきます。
起動
準備が終わればVMを起動するだけで、勝手にプロビジョニングされます。re:dashのVagrant Boxが事前にダウンロードされていない環境では、少し時間がかかると思います。
$ ./bin/vagrant_ctl.sh start
動作確認
上記のコマンドでVM起動すると、 http://localhost:9001 でre:dashにアクセスすることができます。
re:dashの使い方については割愛しますが、クエリを実行して、サンプルDBのデータを参照できていることを確認します。
現時点では、re:dashのデータソースについては手作業で設定することになります。
(念のため上記の画像ではデータをマスキングしています)
まとめ
SQLの入門書として評判のいい書籍の内容をre:dashで勉強できるようにしたので、社内でもっとSQLに興味を持つ人が増えてくれるといいなと思っています。
(追記)worldデータベース
こちらの記事でちょっと言及していただいたので、影響を受けて追記してみました。
SQL書き方ドリルをお持ちでなくても、MySQLのworldデータベースを使用できるようにしました。Gistの Vagrantfile も変更済みです。
worldデータベースを使用する場合は、Vagrantfileと同じ階層にworld.sql.gzを配置してください。
