傘が必要か通知する bot を作った
注意：今回は趣味全開の内容です。
ことりちゃんが毎朝 Slack に今日傘が必要か通知する bot を作りました。
その日の降水確率が 50% を超えている時は、傘を忘れないよう Mention 付きでメッセージを投稿します。
これで、傘を忘れてびしょ濡れになることは少なくなるはず。
経緯
- 3月初旬に傘を持って行かずびしょ濡れになり、後悔した
- 毎朝傘を持っていくべきか調べて出勤するのは面倒臭い
- 自分で作りたかった
という理由から、毎朝 Slack に傘が必要か通知する bot を作りました。
ソースコード
使用技術
- Heroku
- Ruby
- Rake
- Slack(Incoming WebHooks)
Heroku Scheduler を利用し、指定の時間に傘が必要か Slack に通知する Rake タスクを実行しています。
Slack への通知は Incoming WebHooks を利用しています。
降水確率の取得
傘の必要性はその日の降水確率から判断しています。
天気予報の Web API は種類があったのですが、降水確率を取得できる Web API はあまり見つけられず。
今回は 気象庁の天気予報情報を XML で配信 - drk7jp を利用しました。
指定の都道府県・地域の 6時間ごと(00-06, 06-12, 12-18, 18-24)の降水確率が取得できるため、1日の最高降水確率によってメッセージを分ける実装にしました。
text = case today.probabilities_of_rain.max when 50..100 # % DANGER_MESSAGE when 40..50 # % CAUTION_MESSAGE else NOTICE_MESSAGE end
その他
heroku は Web 上から簡単に環境変数をセットできるため、 都道府県・地域・IncomingWebHook URL・メッセージは環境変数を利用して切り替えられるようにしました。
まとめ
趣味全開ですが、heroku を試すこともでき、実用性もあるので良しとしますw
技術情報の集め方
私の技術ネタ、情報の集め方を紹介
通勤中はこれらのページをざっくり見て、情報を集めています。
気になる記事をお気に入りして後でじっくり読んだり、帰宅して触ってみたりしています。
はてなブックマーク
はてなブックマークのテクノロジーカテゴリ
スマホアプリで閲覧しています。
Qaleidospace
Qiita のランキングサイトです。
期間を指定できるのも良いところです。
どんな技術が流行っているのかをチェックするために使っています。
GitHub(Trend)
GitHub ではトレンドランキングが表示できます。
言語で絞ることもできるので、私は Ruby, Java, JavaScript のトレンドを見ています。
世界的にどのような言語・ライブラリ・FWが人気なのか、動きが活発なのかをチェックしています。
こんな感じで毎日情報を集めています。
是非自分にあった情報の集め方の参考になればと思います。
構成管理ツールを作ってみた
siman(シーマン) という構成管理ツールを作りました。
(SImple configuration MANagement tool の略です。seaman ではありません。)
Vagrant で仮想マシンを作るたびに環境構築するのが面倒だったので、楽にするためのツールを作成しました。 Chef よりもさらにシンプルに、Ruby を使わずにできたらと思いこの形になりました。 Chef の様にリモートサーバの構成管理は行えません。
"No." "実行内容" "レシピ(シェルスクリプト)の URL"
の形式でメニューを作成し、siman を実行すると
レシピを DL し、順次実行します。
冪等性を保つために、メニューの何番目まで実行したか記憶しています。 既に実行済みのメニューは再度実行されません。
レシピは URL 形式で指定するため
な感じでリポジトリに置いたシェルスクリプトの URL を指定したり、 Gist の URL を張るなりして使用します。
例えば、私は Rails の環境をよく作るので
rbenv を install -> ruby 2.2.3 を install -> rails を install といったメニューを作成しました。
(URL は git.io で短絡しています。)
001 install_rbenv https://git.io/vzohD 002 install_ruby_223 https://git.io/vzohy 003 install_rails https://git.io/vzohH
インストール方法等は siman/README.md at master · mmts1007/siman · GitHub を参考にしていただければと思います。
Ruby Enumerable#group_by を使ってみた
DB から取得したデータを Ruby 上でグルーピングしたくてドキュメントを漁っていたら見つけたので紹介。
経緯
DB に入っている
| id | task_type_id | task_id |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 1 | 3 |
| 4 | 2 | 4 |
| 5 | 2 | 5 |
| 6 | 2 | 6 |
こんな感じでデータを
[
{
task_type_id: 1,
task_id: [1, 2, 3]
},
{
task_type_id: 2,
task_id: [4, 5, 6]
}
]
こんな感じにタスクの種別に紐付いているタスクの一覧 JSON を Ruby で作りたかった。 task_type_id でグルーピングされた値が取れれば と思い、繰り返し関係を提供している Enumerable モジュールのドキュメントを漁った。
結果
案の定欲しいメソッドはあった。メソッド名見た瞬間、「これ！」ってなった。
instance method Enumerable#group_by (Ruby 2.2.0)
使い方
# DB から取得したデータ records = [ { id: 1, task_type_id: 1, task_id: 1 }, { id: 2, task_type_id: 1, task_id: 2 }, { id: 3, task_type_id: 1, task_id: 3 }, { id: 4, task_type_id: 2, task_id: 4 }, { id: 5, task_type_id: 2, task_id: 5 }, { id: 6, task_type_id: 2, task_id: 6 } ] records.group_by { |record| record[:task_type_id] } # => {1=>[{:id=>1, :task_type_id=>1, :task_id=>1}, {:id=>2, :task_type_id=>1, :task_id=>2}, {:id=>3, :task_type_id=>1, :task_id=>3}], 2=>[{:id=>4, :task_type_id=>2, :task_id=>4}, {:id=>5, :task_type_id=>2, :task_id=>5}, {:id=>6, :task_type_id=>2, :task_id=>6}]}
ということで、task_type_id でグルーピングされた値を取得することができた。
後はデータの形式を求めている形に変換すれば完了
records.group_by { |record| record[:task_type_id] }
.map { |k, v| { task_type_id: k, task_id: v.map { |e| e[:id] } } }
(group_by の後の map が分かりづらい気がする…。また考えよう。)
JJUG CCC 2015 Fall に行ってきた
2015/11/28 (土) に開催された JJUG CCC に行ってきました！
JJUG CCC 2015 Fall（11月28日開催） | 日本Javaユーザーグループ
各セッションのスライドは下記サイトにまとめられているようです。
今回は下記セッションを聞いてきました
EF-1エバンジェリスト直伝！Kotlinを既存プロダクトで使う！
JVM で動くプログラミング言語 Kotlin の紹介でした。
Kotlin の概要から実戦へ投入する場合の方法等を紹介していました。
AB-2 Javaエンジニアに知っておいて欲しい「KDDIクラウドプラットフォームサービス mBaaS by Kii」によるアプリ開発
mBaaS の説明でした。
mBaaS が流行ったら、バックエンドエンジニアの需要って減るのかなーなんて恐怖を感じていました。
CD-3 よくある業務開発の自動化事情
「あるある！」って頷きながら聞いていたセッションでした。
スピーカーの方の話し方が面白かった！
自動化はしたい、しなければと思っているけどどこの現場も苦労しているのかなと感じました。
www.slideshare.net
CD-4 クラウドネイティブアプリケーションとSpring Framework
マイクロサービス、クラウドネイティブといった技術を Spring, Netflix OSS 等を用いて紹介する内容でした。
Spring Cloud, Service Discovery, Histerics, cirkit breaker, Config Server などのクラウドネイティブのための技術が素晴らしいなと思いました。
また、いつかは業務で実戦したいと思いました。
(趣味でやるとしたら…自分でサービス立ち上げるしか！)
AB-6 【こっそり始める】Javaプログラマコーディングマイグレーション
このセッションも「あるある！」って感じでした。開場もよく笑いが起きていましたw
現場に新しい技術を入れていきたい私としてはとても参考になるセッションでした。
ピープルウェア読んでみたいなーと思いました。
www.slideshare.net
GH-7 てらだよしおの赤裸々タイム
Java と Windows 主に Azure 関連のお話だったり、てらださんへの質問だったりというお時間でした。
てらださんにとっては魔の時間だったのかと思いますw
まとめ
JJUG CCC などの外部のセミナーは最新技術などを学べるのですごく刺激になります。
特に今回は Kotlin, クラウドネイティブアプリケーション、Javaプログラマコーディングマイグレーションに興味を持ちました。
あと、今回初めて懇親会に参加させて頂きました。
LT がとても楽しかったです。そして、じゃんけん大会勝ちたかった…。
次回は今回興味を持った Kotlin について記事を書ければと思います。
Node EasyMock で API モックサーバを作る
Node EasyMock を使って、API モックを作ってみた。
フロントエンド：Angular JS
バックエンド：Spring Boot
という感じでアプリを作っているのですが、フロントエンドから作りたくなったので使ってみました。
インストール
基本的には README の通り
$ npm install -g easymock $ easymock
で動作しました。
ただし、node のバージョンの指定があるようで v5.0.0 で実行したときに下記のメッセージが表示されました。
wanted: {"node":">= 0.10.0 < 0.11.0 || >= 0.11.13 < 0.13.0 || >= 1.0.0 < 2.0.0"} (current: {"node":"5.0.0","npm":"3.3.6"})
ということで、今は v0.12.7 を使用しています。
API モック
Node EasyMock は URL、HTTP Method と対応する JSON ファイルの内容を返却します。
例えば、GET /users をリクエストした場合 users_get.json ファイルの内容を返却します。
[URL]_[HTTP Method].json の形式でファイルを用意するだけで、API モックを作ることができます。
また、/users/1/ などのネストした URL の場合は users ディレクトリ配下に 1_get.json を配置します。
ログとドキュメント
Node EasyMock はログとドキュメントを表示する機能もあります。
/_documentation/ にアクセスすると API ドキュメントを表示することができます。
ドキュメントでは API の一覧を確認することができます。
エンドポイントをクリックすると、対象のエンドポイントのレスポンスを確認することができます。
同様に /_logs/ にアクセスすると、アクセスログを確認することができます。
まとめ
フロントエンドの開発とバックエンドの開発が並行して進む場合など、バックエンドがまだ出来ていないときに利用してみてはいかがでしょうか？ JSON ファイルのみ用意できれば使用できるので、学習コストも低くて良いと思います。
GitHub を使ったプロジェクト管理ツール Waffle を使ってみた
先日面白い記事を見つけました。
GitHub の issue、Pull Request を使ってプロジェクト管理を行うためのツールです。
この中でも、Waffle が使いやすいというコメントをいただいたので、早速使ってみました。
使い方
画面はこんな感じです。
Backlog, Ready, In Progress, Done にカラムが分かれていて、 ドラッグ＆ドロップで issue を移動させることができます。
また Waffle はコミットコメント、Pull Request のコメントを使って issue を移動させることができます。
close #xx、fix #xx のようにキーワードと issue 番号を記述した Pull Request がマージされると、対象の issue をクローズ してくれます。
サンプルとして「ワッフル テスト issue」という issue を作成しました。
この issue を自動的にクローズさせます。
自動的に移動させるには前述のとおり キーワードと issue 番号 をコミットコメントに含める必要があります。
キーワードは下記のとおりです。
- close, closes, closed
- fix, fixes, fixed
- resolve, resolves, resolved
「ワッフル テスト issue」は #17 のため
$ git commit -m "fix #17"
とコミットコメントに記載することで自動的に issue をクローズします。
コミットしたブランチを Push し、Pull Request を作成します。
すると、issue と Pull Request が紐づけられ、自動的に issue が In Progress に移動します。
最後に Pull Request をマージすると issue, Pull Request が Done に移動します。
これで issue を自動的にクローズさせることができました。
issue と Pull Request の紐付き
この記事を書くために Waffle を触っていたのですが、
前述のとおり issue と Pull Request が 1つに合わさったような見た目になる場合と、ならない場合がありました。
結果として Pull Request のタイトルもしくはコメントにキーワードと issue 番号を含めた場合 1つに合わさったような見た目になることがわかりました。
コミットコメントに issue 番号を入れれば、クローズすることはできるので、
最低限コミットコメントにキーワードと issue 番号を含め、
余力があれば Pull Request のコメントに書くことで
どの Pull Request でどの issue が対応されたのか さらに分かりやすくなるのではと思いました。
まとめ
コミットコメントにキーワードと issue 番号を書くだけで、ステータス管理をしてくれるのはとても楽だと感じました。
SCM、チケット管理 etc... 様々なツールを使うとあちこち見なければいけないので、1つにまとまってるのは良いですね。
