【Ruby】可変長引数と配列の展開

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、メソッドの引数に関することで 可変長引数と配列の展開を調べました。

環境

• max OS X Sierra
• Ruby 2.3.0

前提条件

• irbかPryが動作すること

やり方

可変長引数

可変長引数のサンプルソース

実行

[12] pry(main)> # 引数を元にメッセージを表示する
[13] pry(main)> def display_messages(name, *messages)
[13] pry(main)*   messages.each do |message|
[13] pry(main)*     p "#{name} : #{message}"
[13] pry(main)*   end
[13] pry(main)* end
=> :display_messages
[14] pry(main)>
[15] pry(main)> # 実行
[16] pry(main)> display_messages 'John', 'Hello', 'Goodbye', 'Thank you'
"John : Hello"
"John : Goodbye"
"John : Thank you"
=> ["Hello", "Goodbye", "Thank you"]
[17] pry(main)>

値を個別に渡していますが、2つ目以降は配列として受け取られているのがわかります。

可変長引数

配列の展開のサンプルソース

実行

[39] pry(main)> # 引数を元にメッセージを表示する
[40] pry(main)> def display_messages(name, message_first, message_second)
[40] pry(main)*   p "#{name} : #{message_first}"
[40] pry(main)*   p "#{name} : #{message_second}"
[40] pry(main)* end
=> :display_messages
[41] pry(main)>
[42] pry(main)> # 実行（正常動作）
[43] pry(main)> messages = %w(Hello Goodbye)
=> ["Hello", "Goodbye"]
[44] pry(main)> display_messages 'John', *messages
"John : Hello"
"John : Goodbye"
=> "John : Goodbye"
[45] pry(main)>
[46] pry(main)> # 実行（例外発生）
[47] pry(main)> # 受取先のメソッドの引数以上に渡した場合、エラーとなる
[48] pry(main)> messages.push 'Thank you'
=> ["Hello", "Goodbye", "Thank you"]
[49] pry(main)> display_messages 'John', *messages
ArgumentError: wrong number of arguments (given 4, expected 3)
from (pry):50:in `display_messages'
[50] pry(main)>

まとめ

最初見た時は「なんだこれ？」と思いましたが、コーディング量が減るのはいいことで
使えるところには積極的に使っていきたいです。

ただ、変数名などをちゃんとしないと変に勘違いする可能性もあるかな？と思ったので
要注意のものだと感じられ巻いた。

参考資料

改訂2版 パーフェクトRuby

【Rails】Hash(key)をシンボル形式にする

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、APIなどで取得したHash値をRails側で処理しやすいようにするため
deep_symbolize_keysを調べました。

環境

• max OS X El Capitan
• Ruby 2.3.1
• Ruby on Rails 4.2.6

前提条件

• Railsアプリケーションのひな形が作成された状態で、Railsコンソールが起動できること

やり方

サンプルデータ

{
    "name": "Taro Tanaka",
    "gender": "male",
    "age": 24,
    "frends": [
        {
            "name": "Hanako Tanaka",
            "state": "NY"
        },
        {
            "name": "Jiro Tanaka",
            "state": "LA"
        }
    ]
}

実行

[1] pry(main)> response = {"name"=>"Taro Tanaka", "gender"=>"male", "age"=>24, "frends"=>[{"name"=>"Hanako Tanaka", "state"=>"NY"}, {"name"=>"Jiro Tanaka", "state"=>"LA"}]}
=> {"name"=>"Taro Tanaka", "gender"=>"male", "age"=>24, "frends"=>[{"name"=>"Hanako Tanaka", "state"=>"NY"}, {"name"=>"Jiro Tanaka", "state"=>"LA"}]}
[2] pry(main)> response.deep_symbolize_keys
=> {:name=>"Taro Tanaka", :gender=>"male", :age=>24, :frends=>[{:name=>"Hanako Tanaka", :state=>"NY"}, {:name=>"Jiro Tanaka", :state=>"LA"}]}
[3] pry(main)>

おぉ、シンボル化されたものになりました。
ちなみに「deep」とあるので、deepではないものを使うとどうなるか確認します。

[3] pry(main)> response.symbolize_keys
=> {:name=>"Taro Tanaka", :gender=>"male", :age=>24, :frends=>[{"name"=>"Hanako Tanaka", "state"=>"NY"}, {"name"=>"Jiro Tanaka", "state"=>"LA"}]}
[4] pry(main)>

なるほど、配列化されたところはそのままということですね。
基本的にはすべてシンボル化するはずなので、deep_symbolize_keysを使うことになりそうです。

参考資料

deep_symbolize_keys (Hash) - APIdock

【アジャイル】アジャイル(スクラム)をやり始めて2ヶ月ほど経ったので振り返る

はじめに

本エントリーは以下の続きです。

fujiyasu.hatenablog.com

報告会とかあっても良さそうなのですが、走り始めなのと
業務時間はチケット消化に忙しいのでその場もなかなか設けられずな状態です。

なので、丁度GWということもあり
整理も兼ねて一度書いてしまおうと思います。

これを元に会社の技術ブログや何かの登壇のキッカケになればいいですね！

スクラムチームメンバー

基本に則り、以下のメンバー数となります。

• プロダクトオーナー（以下、PO）
• スクラムマスター（以下、SM）
• 開発チーム（8人）
• スクラムコーチ（毎日はいない）

アジャイルでやることについては、慣れもあるので
開発チームは段々と成長していくと思います。

SMの存在が1番重要

チームで1番重要だと思ったのが「SM」の存在でした。
開発チームを円滑に進めるための手助けとしているわけですが
結局、人間同士のやり取りとなるので人間として出来ている人が
SMとして適任だと感じられました。

もっと具体的に言うと

1. SMをやる人が自分の部や課の中堅どころであり、
   上長にも一目置かれている
2. 他の部署にも顔が利き、すぐに連携が取れる
3. 自分のスキルよりも、まずチームのことを考えて行動できる

上記のスキルを持ったがSMになれば、駆け出しチームでも
チームを成長させていき、軌道に乗せていけると存在であり
スクラムチームを作る上でとても重要だと今回思いました。

開発チーム

今までやってきたものもあるので、現在、得意分野（アプリが得意ならアプリなど）を
担当しているのが現状です。
チームが成熟していくに連れて、その垣根も越えて全員がある程度のことが
できるようになっていくと思います。
※自分は手を広げすぎるとどれも中途半端になりそうなので、
しばらくサーバーサイドかな？と思っていますが。

また、若手が半数、中堅が半数となっており、また半数ずつということで
自然に師匠と弟子という形にもなり、業務を通じての教える、教わるという
体勢ができています。

まさかここまで考えてメンバーを選抜したのか？というぐらい、
うまくいっている感じがしており人員配置を考えた
マネージャーはすごいなと思わされました。

アジャイルプラクティス

導入した大まかなプラクティス

1. プロダクトバックログ
2. スプリントプランニング
3. デイリースクラム
4. 開発作業
5. スプリントレビュー
6. スプリントレトロスペクティブ

初めてやるので「基本に忠実に」ということでやっています。
現在うまくやれているので、チームの成熟度に合わせて
どんどん洗練されていくと思います。

導入した細かなプラクティス

1. 1日1回のスクラムチームミーティング（期間限定）
2. プランニングポーカー
3. バーンダウンチャート
4. バーンアップチャート

1以外はプラクティスもあるので、説明不要だと思います。
1については、スクラムマスターの判断で導入したものです。

業務をやっていく中で、週1の定例では遅いということで
開発スピードは落ちるにしろ「1日1回問題をキャッチアップする」を
目的にMTGを実施しています。

結果は、やって正解でした。
やはり新しいことをやると必ず問題が出てきて、すぐに議題に上げることが
できるようになり、その場で解決（または相談）することができ
MTGが多くなるにしろスクラムチーム立ち上げ時はなるべくやった方が
いいと思いました。

問題点

もちろん、すべてうまくいっているわけでもありません。
今回やってきた中で問題となっていたものは以下の通り。

1. チーム立ち上げ時はミーティング多い
2. すでにローンチ済みのサービスのため、本番の調査依頼などが入ってくる
3. チケット消化がメインとなっているため、立ち上げ当初に作ったものの見直しがない
4. POがいない問題

1については、立ち上げ時特有の問題だと考えています。
チーム全員が同じ目線で同じ目標に向かうためには、全員出席で認識合わせを
しなければならないため、根気よくやるべきだと思いました。

2については、自分が携わっているプロダクトの問題なのかもしれませんが
バックログ以外のタスクが割り込みとして入ってきて、進捗に影響しています。
良くはない状況ですが、それを見越してのベロシティを出すのもありと言えばありです。
しかし、割り込みはない方がいいはずなので、そのへんも改善も今後の課題となります。

3については、スクラムに限らず通常のシステム開発でもあるあるだと思います。
ただ「1週間に1回見直そう」というのも短すぎだと思うので、3ヶ月に1回など
その感覚が良いのでは？と思い始めました。今度、スクラムマスターに相談してみよう。

4については、自分のチームだけでなく他のところでもあるあるだと思います。
しかし、この問題はPOもちゃんと認識しており、意識してチームの近くに
いるようにしてもらえています。
当たり前のことだと思わがちですが、ちゃんとPOに問題点を言えて
お互い改善していけてるところがあり「いいチームだな」と認識させられます。

現状とまとめ

2ヶ月ほど経ち、振り返ってみましたがいい感じにまわり始めたと思います。
ただ、スプリントはまだ回数が少ないため、安定したとは言えない状況です。
こればかりは数をこなしていき、安定させ価値あるものをどんどんリリースして
いければと思います。

【教育】2017年度：プログラマの新人教育について簡単にまとめてみました

はじめに

前職で3年ほどプログラマの新人教育に携わってきました。
この時期になると、みな同じことを思うのか2013年に書いた記事への
アクセス数が多くなる傾向があります。（2年見たので間違いない）

転職して1年経ち、今の会社の新人教育も見てきたので
今一度、自分が思っている（考えている）プログラマの新人教育について
書いていきます。

なお、このエントリーは個人の見解であり、所属する組織の公式見解ではありません。

今回のエントリーについて

新人教育というと広く考えられるので
今回は、以下の状況を想定して書いています。

共通の定義

1. Webサービスを作っている会社を想定
2. 会社の大きさやサービス数は関係ない
3. フロントエンド、サーバーサイド、インフラという分野があるが、Webサービスを作ることを想定

新人の定義

今回、対象としている新人の定義は以下の通りです。

1. 社会人1年目の新人
2. 大卒、専門卒、高専卒などは関係ない
3. 学生のところから、アルバイトでシステム開発に携わっていない
4. 入社直後からメンター（先輩）がいる（またはいない）
5. 学生のレベル
   1. 文系：プログラミング経験なし
   2. 理系：授業でプログラミングを経験、基本情報処理技術者の資格を取れるレベル

3以外は、ほとんどの人に当てはまるのではないでしょうか。
3についてすでに社会人としてやっているようなものなので問題ないと判断します。

なので、今回は上記の定義を元に書いていきます。

社員の定義

逆に社員の定義も明記していきます。

1. メンター（教育担当）として抜擢された
2. プログラマとして、一通り（要件、設計、開発、テスト、リリース）のシステム開発は携わった
3. 新人教育に対して、ある程度のモチベーションがある

こんなところでしょうか。 1番大時なのは、3だと考えています。
これがないと、結局「他人に対して何かをしてあげている」という考えになり
新人教育に対してのモチベーションが下がってくると思います。

本題

メンター（教育担当）になった場合

大体は、内定式〜入社式1ヶ月前ぐらいに上司から言われるのではないでしょうか。
ここで断ってもまったく問題ないと思います。自分の力をつけるのも必要なことですし。

逆に引き受ける場合、以下のことを考えて引き受けるのがいいと思います。

• 教育を通してメンバーになってもらうことで、チームを作り上げるため
• 自分の力を棚卸しする目的として、とても良い機会のため

教育は何すればいいのか？

何をすればいいのかは以下の通りです。

• 開発の全体フローを教える
• Webシステムの概要を教える
• 実際に開発をしてもらう

詳しく書いていきます。
なお、教育コンサルな人ではないので「自分だったらこうする」レベルで書きます。
もっと効率良いやり方やうまいやり方などは実際にそういう会社にお願いした方が良いです。

開発の全体フローを教える

自分もそうだったのですが、おそらく学生は「プログラミングをしたい」という気持ちが強いです。
特にテストなんて苦痛（今もですが）なことなので、まず開発の全体フローを教えることが大事です。

ちょうどいい本はこれでしょうか。

ずっと受けたかったソフトウェアエンジニアリングの授業1 増補改訂版

Webシステムの概要を教える

いきなり、JavaやPHPをやっても
「その言語で書けるだけあって、全体を把握していない」
という状況にそのうちなります。
※自分がそういう状況なので、今苦労しています。

なので、最初の内にしっかりと教育した方が良いです。

ちょっと古いですが、この本が1番わかりやすく読みやすいと思い昔から使っています。

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

最近はもっとコンパクトなものが出ています。

イラスト図解式 この一冊で全部わかるWeb技術の基本

実際に開発をしてもらう

講義形式はある程度で終わらせて、実際はここがメインになると思います。

パターンとしては二通りあります。

• 研修期間がある場合
  • サンプルプロジェクトを立ち上げて実際にアプリを作ってもらう
• プロジェクトに参画した場合
  • メンター（教育担当）と二人三脚で開発をする

サンプルプロジェクトの場合
「メンター（教育担当）が顧客として、新人にシステム開発を依頼する」というので
仮想プロジェクトを動かす形でいいと思います。

作るものは、研修期間にもよりますが、短い期間でも「Webサービスとして動くもの」とします。
新人に要件定義をさせて、設計、製造、テスト、リリースを実際にやってもらうことで
全体を把握してもらうことを目的としています。

プロジェクトに参画した場合
研修期間もあまりなくすぐに業務に入る場合、プロジェクトの上層部に相談して
「新人とセットでシステムを作る」スケジュールにします。

それぞれが業務に入るとお互い何をやっているかわからなくなり、意思疎通がやりにくくなり
メンター（教育担当）としての意味がなくなってしまいます。

Q/A

会社が新人教育をまとめてやり、その後配属が決まるパターンがある

場合によって、このパターンがあると思います。
この場合、メンター（教育担当）のアサインが数ヶ月遅れるだけであまり変わらないです。
なので、自分がメンター（教育担当）になる動機を考えた上で引き受けるのがいいと思います。

すごい新人で要領がいい

この歳になると、自分もかなり感じることです。
メンター（教育担当）はどうすればいいのかは自分も悩みました。

そして、結論として
「逆に新人から教われるところは教わる」
「逆に質問がきたら答えられる範囲で答え、わからなければ一緒に考える」
ということです。

メンター（教育担当）になったとしても、すべてを知っているわけではなく
「すべて答えられるようにしないと！」というのも難しい話です。

なので、変なプライドなどは捨てて「教えてもらう」「一緒に考える」をして
「メンバーとしてお互いを助け合って、信頼関係を作る」というのを考えながら
やっていった方がいいです。

新人の成長速度が異なる

新人も人間なので、成長スピードに差が出るのは当たり前です。
例えば、数ヶ月で物にする人がいて、半年経てば「後は1人でできるだろう」と思える人もいれば
根気よく教えて、1年後急成長する人もいます。

メンター（教育担当）として、新人の性格と成長速度をちゃんと見て
その人にあった教え方、教育プランを考えてあげる必要があります。

教育が段々と辛くなってくる

目標があり担当となったが、教えることはとても大変なことです。
担当になったからには「1人で頑張ろうという」という気持ちになります。

ただ、それでは限界があるので対策としては
「他の人にも教育してもらうようにする」
これを事前にチームメンバー（または上司）に伝えておくことが大切です。

まとめ

考えていたことをまとめようとすると文章にする難しさを感じました。
しかも、具体的な方法を書いていないので読んでくれた人のためになるのかな？と思いつつ
教育の何かのためになれば嬉しいです。

また、具体的に何か話したい（聞きたい）ことがありましたら
気軽に連絡してもらえればと思います。

【API Blueprint】【API仕様書】API仕様書をAPI Blueprintで作成して、モックサーバーを立てる

はじめに

業務でAPIに関するところに携わることになりました。
昔ながらのやり方だと、仕様書＝Excelということになりますが
「仕様書もコード化をしないと！」と考え、API Blueprintを使い
API仕様書を作ることにしました。

API Blueprint | API Blueprint

自分だけノウハウを持っていても、もったいないので
ブログに書いてやり方を広めて行きたいと思います。

API仕様書をAPI Blueprintで書くメリット

新しいものを導入する場合、チームの合意が得られないと導入できません。
その手助けになるようメリットを列挙していきます。

・マークダウン形式にすることにより、仕様書のレビューがしやすくなる。
Excelの場合だと、ファイル単位でバージョン管理できますが
ファイルの中身まで差分を見れません。

そのため、履歴シートを作り、修正したところを赤文字にしたりと
かなり手間がかかります。これは作業効率が落ちる要因となります。

マークダウンにすることにより、Gitで見た場合
詳細に差分を確認することができレビューしやすい状態にできます。

・HTML出力することにより、ブラウザで仕様書を確認できる。
わざわざExcelのアプリを立ち上げて仕様書を見るというのは辛いです。
Googleスプレッドシートもありますが、Googleアカウントではない場合
使うことができません。

なので、HTMLファイルとして出力することにより誰でも簡単に
仕様書を見ることができます。

・脱Excelをすることができる。
WindowsでもMacでも仕様書が大きくなるにつれ、Excelが重くなり
よく落ちることに見舞われないでしょうか？それを無くすことができます。

パッと思いつく限りではこんな感じでしょうか。

環境

• maxOS Sierra
• nodebrew
  • Node.js v7.8.0
• 筆者、gulp, Node.js経験ほとんどなし

前提条件

• ローカルマシンでNode.jsが動くこと

やり方

サンプルで作ったものは、GitHubに上げてあります。

github.com

Nodeライブラリのインストール

各種ライブラリを使うため、インストールを行います。

$ npm install

上記を実行すると「node_modules」に必要なライブラリが入ります。
こうしておくことにより、プロジェクト単位でライブラリ管理ができます。

gulpの実行

API仕様書を更新した際、手動でHTML生成するのは大変なので
「gulp-aglio」と「browser-sync」を使い、自動生成されるようにしました。

起動の仕方はターミナルで以下のコマンドを実行するだけでOK。

$ node_modules/.bin/gulp

そうすると起動時にログが出力され動いている状態となります。

[14:53:32] Y_Fujikawa:sample-api-document git:(master) $ gulp
[15:23:36] Using gulpfile ~/project/sample-api-document/gulpfile.js
[15:23:36] Starting 'combine'...
[15:23:36] Starting 'watch'...
[15:23:36] Finished 'watch' after 9.58 ms
[15:23:36] Starting 'browserSync'...
[15:23:36] Finished 'browserSync' after 89 ms
[15:23:36] Finished 'combine' after 137 ms
[15:23:36] Starting 'generate-api-docs'...
[BS] Access URLs:
 ----------------------------------------
       Local: http://localhost:8088
    External: http://XXX.XXX.XXX.XXX:8088
 ----------------------------------------
          UI: http://localhost:3001
 UI External: http://XXX.XXX.XXX.XXX:3001
 ----------------------------------------
[BS] Serving files from: ./
[15:23:38] Finished 'generate-api-docs' after 1.49 s
[15:23:38] Starting 'default'...
[15:23:38] Finished 'default' after 61 μs

この状態でマークダウンで仕様書を更新すると、自動的にgulpが実行され
API仕様書がマークダウンファイルとHTMLファイルで作成されます。

モックサーバーを起動して、APIの戻り値を確認する

チームメンバーから「モックサーバーがあると良い」という話を受けました。
モックサーバーのために時間をかけて、サーバーを用意するのもどうかと思い
探していたところ、API Blueprintにはモックサーバーをローカルマシンに
起動させるライブラリをがあるようです。

それが「drakov」というものでした。
他にもいろいろあったのですが、今回はこれを使うようにしました。

実行の仕方は以下の通り。
なお、オプションで「watch」はファイル変更時のでき
「public」はローカルマシン以外からアクセスできるようにするものです。

node_modules/.bin/drakov -f "index.md" --watch --public

実行をするとログが出力され、起動している状態になります。

[INFO] No configuration files found
[INFO] Loading configuration from CLI
   DRAKOV STARTED
[LOG] Setup Route: POST /v1/user/list ユーザリスト取得
[LOG] Setup Route: POST /v1/admin/item/list 商品リスト取得
   Drakov 1.0.3      Listening on port 3000
   PUBLIC MODE      running publicly
 FILE SPY   ACTIVE

想定した、ものが返ってくるか確認するためcurlでAPIを実行してみます。

[15:38:17] Y_Fujikawa:~ $ curl -XPOST -H "x-sample-api-access-token: xx" -H "Content-Type: application/json" http://localhost:3000/v1/admin/item/list
{
  "result_code": "0",
  "item_list": [
    {
      "id": 9876,
      "name": "りんご",
      "stock": 100
    },
    {
      "id": 8765,
      "name": "バナナ",
      "stock": 0
    }
  ]
}%

おぉ、問題なくAPIが返ってきました。

GitHub Pagesを使ってAPIドキュメントを表示させる

HTMLファイルまで出力できましたが、いちいちファイルを開いてみるのは
ナンセンスだと思い、サーバーでも用意しようかな？と考えました。
しかし、わざわざこのためだけにドキュメントサーバーを用意するのは
手間だったので、GitHub Pagesを使うことにしました。

やり方は以下の通り。

そうすると、以下のURLでアクセスすることができます。

https://y-fujikawa.github.io/sample-api-document/

まとめ

「結局、Excelで管理していたのね・・・」ということがあり
今回、API BlueprintでAPI仕様書を作成する方法を模索して、プロジェクトに取り入れることができました。

API Blueprint自体はだいぶ前からありますが、実際にプロジェクトで使っているという
話は聞かないので、これを機に「バリバリ使っています！」という話を聞ければと思います。

また「Excelからマークダウンにして、バージョン管理しよう！」ということに
発展するプロジェクトに少しでも役立てれればと思います。

参考サイト

API Blueprint | API Blueprint

【API Blueprintの使い方】Web APIの仕様書を書く・読む・実行する ｜ Developers.IO

aglioでAPI Blueprintを使ったドキュメント作成環境をローカルに構築する - dackdive's blog

aglioとdrakovでAPI仕様書とMockを生成する手順 | takemikami's note

【アジャイル】アジャイル(スクラム)をやれるチャンスがきたので考えを整理する

はじめに

ちょうど2年前に以下のエントリーを書きました。

fujiyasu.hatenablog.com

ただ、前の会社では自分の力不足により断念した感じでした。
しかし、今一度やれるチャンスが出てきたので、考えの整理にも兼ねて
書いておきます。

やること

上長以上の人にアジャイルを理解してもらった上でやる

当たり前のことだと思うのですが、このバックグランドがあるのとないのとでは
「業務でやるアジャイル」はできないと考えます。

「よくわからんがやりたいからやらせている」ということでは
何かあった際に説明するのが難しいですし、同じ目線で話すことができません。

また、現場ベースからのボトムアップも時には必要だと思うので
「一度会話してOKもらったから」という考えにならずに
いつでも上の人たちに説明できるように準備しておくことも大事です。

アサインメンバー（予定者含む）には事前学習をやってもらう

特に未経験者は「アジャイルって何？」からなので
いきなり「こういうやり方でやっていきます！」とリーダーっぽい人から
言われるとその方向に目線が行ってしまいチームとして機能しにくくなると思います。

なので、まず事前学習をしてもらうようにするのが良いと考えました。

学習に最適なものは以下の通りです。

アジャイルサムライ−達人開発者への道−

言わずと知れたサムライ本です。
厳密的にはスクラムではありませんが「アジャイル」とはなんぞや？
というのを広く浅く学べる本です。

SCRUM BOOT CAMP THE BOOK

スクラムに関する本は他にもありますが、ちょうどいいページ数で
マンガテイストなイラストがあるものでスクラム導入からリリースまでを
簡潔にわかりやすく書かれている本なので、こちらがオススメです。

https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Japanese.pdf

スクラムのことを十数ページで書かれているもので
時間がないときやスクラムってこれでいいんだっけ？というときに読めそうなものです。

他にもいろいろな本がありますが、読む時間も限られているので
最初はこのぐらい読むまでで良いと思います。

プロダクトについて理解をする

アジャイル(スクラム)は、「プロジェクト」に対してコミットするのではなく
「プロダクト」に対してコミットするものです。

なので、事前にどういうプロダクトなのか？というのを理解しておくことが大事です。
実際に使ってみたり、なぜこのサービスを作ったのかを運用者に聞いてみたり。

アジャイル(スクラム)を勉強した人がいたら、舵取りになる

自分も含めて未経験には不安がつきものです。
未経験者に対しては随時フォローを行い、自分の知識を共有していきます。

ただし「リーダー」ではないので、自分の意見が100%にならないように
うまくチームを誘導していくことも意識していければと思っています。

現状

今まさにスクラムの学習（復習）とチーム作り真っ最中であり
形になっていないのが現状です。

ただ、自分が2年前に宣言してやれなかったことが
今やれているので、不安要素はたくさんありますが形になるようやっていきます。

後は、プログラマとしてのスキル上げなくちゃな・・・

【superset】supersetでSQL Labを使い複数テーブルをJOINしたものをグラフ化する

はじめに

業務でBIツールを導入する話となり、re:dashにしようかな？と思いましたが
あえてsupersetを試してみたくなったので、ローカル環境を作り
いろいろとイジってみました。

ただし、UIは非常に直感的ではなく、すぐにグラフ化するところまで
いかなかったので、操作方法を共有するために手順を書きます。

環境

• maxOS Sierra
• Vagrant 1.8.1
  • CentOS6.5
  • superset 1.5.1
  • MySQL 5.6

前提条件

• VagrantからCentOSに接続できること
• supersetがインストールされていてログインできること
• MySQLに下記のデータが設定、登録されていること
  • https://gist.github.com/Y-Fujikawa/22f2fa602a724bf1ed82c80427fd4d40

また、以下のエントリでsupersetで日本語を表示できるようにしておいてください。

fujiyasu.hatenablog.com

やり方

SQLの記述と実行

SQL Lab → SQL Editorで画面を開き、下記のようにSQLを作成します。

select
 tc.birthplace
 , mi.name
 , count(mi.name) as 'count'
from
  trn_sale ts
inner join 
  trn_customer tc on ts.trn_customer_id = tc.id
inner join 
  mst_item mi on ts.mst_item_id = mi.id
group by tc.birthplace, mi.name

Run Queryボタンを押下した結果。

グラフ化

Visualizeボタンを押下して、グラフを作成します。 このとき、Datasource Nameは、一時テーブルが作成されるっぽいので わかりやすい名前がいいと思います。 ボタンを押下すると、未保存状態のグラフ作成画面に遷移します。

棒グラフではわかりずらいので、テーブル一覧にします。 また、nameカラムがないため、Group byにnameを追加して表示させます。 そして、クエリを実行した結果がこちらです。

まとめ

JOIN句を入れたものでも簡単にグラフ化をすることができました。
この手軽さがBIツールのいいところだと思います。

次回は、今まで作ったものをダッシュボードに表示するようにしてみます。