【自作ツール紹介】iOS/AndroidアプリのレビューをSlack/Email通知するNode.jsアプリ「reviewet」

追記（2016/05/29）：メール通知機能、実装しました

タイトルの通りですが、Node.js上で動作するiOSとAndroidのストアレビューをSlackに通知しつつメール通知もできるプログラムを書きました。

作った理由

iOSとAndroidアプリレビューをSlack通知してくれるツールは、

こことか

こことかにあるんですが、

Slack見れない人にも連絡行くようにメール通知してくれるものが欲しいと言われて、 まあ今時メール通知なんて機能が付いてるものなんてなくて、 だったら作ってしまおう！となったのが作った理由です。

でもまだメール通知の機能は実装していないんですけどね。

→2016/05/29追記：実装しました。

Why Node.js !?

メール通知は置いておいて、なぜNodeを使ったかですが、なんとなくこのプログラムが動く環境はHubotも動いてそうだなぁと思ったからです。 実際自分はHubot動いているサーバで動かしてますし、それなら余計なミドルウェアの追加なしで動く方がいいのでNodeで書きました。

Nodeにcheerio-httpcliというストレイピングモジュールや、色々な便利モジュールがあったのもポイント高かったです。

あとは単純に今まで使ったことなかったから使ってみたかった、というのもあるのですが。

Reviewet

プログラムは、レビューを取ってくるということで、review + getの造語で「reviewet」としました。レビュウェットって読むんでしょうか。

以前作ったのはreinsだったので、なんか似てるなぁと思わなくもないです。

動作サンプル

設定ファイルのデフォルトでは

• iOSはiTunes U、
• AndroidはGoogle

のレビュー内容をSlackに通知するようになっています。 Webhook系の設定は変えて貰う必要があるので、README.mdを参考に設定してください。

iOSとAndroidで取れる情報が違うので、表示も少し違っています。
一番の違いはAndroidだとバージョンが取れないので、全てハイフンになっているところでしょうか。日付も時分秒が取れないです。

多言語対応

一応多言語対応しているので、acceptLanguageをenに変更した場合は、以下のような結果になります。

こういうのは他に見なかったので、reviewetの強みかなと思います。
ですが、見ての通りAndroidのRatingが出せてないので、ここらへんが「一応」といったところです。

所感

Nodeのモジュール群はかなり強力でした。

コード整理していない状態だというのもありますが、300行くらいの実装でSlack通知が実現できてしまっているのには驚きます。 メール通知実装しても400行くらいで収まるのではないでしょうか。

この程度のプログラムであればCallback Hellに苦しむこともないので、ツール作成にNodeを利用するのはありだなぁと思いました。

逆に大変だったのが、JavaScriptでクラスどう書こうとか、セレクタで上手く要素が取れないとか、いつものJavaScript問題にハマったぐらいです。 DOM操作もかなり大雑把に作っているんですがNodeの性能が良すぎて何の問題にもなりませんでした。メモリ消費も微々たるものです。

Androidの方はスクレイピングなので、サイトデザインが変更されたら動作しなくなるかもしれませんが、 ぜひreviewetで遊んでみてください。

追記（2016/05/29）：メール通知機能、実装しました

これで日本語レビューに対しては、機能を満たせました。
新しくfsモジュールを導入しているので、更新の際はnpm installも一緒にお願いします。

出力されるメールのサンプルは以下の通りです。メールはOS毎に別メールで届きます。

しかし、こう否定的なレビューが並んでいると、自分が作ったものでなくても辛いですね・・・

SMTPでアカウント認証が不要な場合は、smtp.email.auth.userの値を空にして貰えれば大丈夫なはずです。 何かあればコメントかIssueで連絡をお願いします。

第3回 ShangriLa MeetUpの振り返り

ShangriLa MeetUp

第3回目となる、ShangriLaのMeetUpを先日の4/9（土）に秋葉原で実施しました。
（ShangriLaは、OSSコミュニティの秋葉原IT戦略研究所が作成している、アニメ情報のIT化プロジェクトになります。）

3回目ですが、コミュニティのメンバー以外にも募集をかけたのは今回が初めてでした。 会場費の都合上、参加費が1000円必要なMeetUpでしたが、それでもたくさんの方に来て頂いてありがたかったです。

参加してくださった皆様、ありがとうございました。

秋葉原IT戦略研究所の紹介と今後の活動について

自分はとある理由で秋葉原を駆け巡っていたので、前半遅刻して会場入りしました。 開場に入ったタイミングでは、既に秋葉原IT戦略研究所の活動紹介が行われており、 慌てて次のLT大会の準備を始めました。
※写真は活動内容発表中の様子です。

LT大会

一人持ち時間5分のLT大会です。私を除く5名にLTをして頂きました。

LTの内容は、

• 「こんなの作りました。」
• 「こんなのやってきました。」
• 「こういうのやっていきたいです。」

といった内容が主でした。

どなたも資料が作りこまれていて、とてもいいLTでした。（なので切り辛かったです）

後半のディスカッションのセクションでも話題に上がったのですが、 これほどたくさんのサービスがあっても、知られることなく埋もれているのは、もったいないですね。

資料を細かく見たいのですが、資料はどうなんでしょう、公開されるのかな？ 進行だと気がそぞろになってしまうので、資料見返したいんですよね。

まあ、その、問題もありまして、

LT大会は私が進行を担当したのですが、 かなり時間がないことを周りにうまく伝えることができず、 結果、かなり時間を押させてしまいました。

大体一人切り替え時間も合わせて8分ぐらいかかっていました。辛い。。

ちなみに

私のLTは、もう時間がなくなるのが予想できていたので、 予定していた『最強ヒロイン琥珀さん』は止めて、 LTの進め方説明と、今後取り組むプロダクトに関する私の希望を話させて頂きました。

そして、秋葉原を駆け巡って買ってきたボルヴィック（といろはす）をお配りさせて頂いたのですが、

なぜボルヴィックだったのか、気付いてくれる人がいなかったのが残念でした。

空の境界、未視聴の方は是非観ましょう！（原作もね！）

ちなみに水は、このネタをやりたいがための個人スポンサードです:)

ディスカッション

『ITでアニメと秋葉原に革新を起こすプロダクトとは』というテーマで、 参加者全員でボードに各自の意見を貼りながら、想いを束ね、 今後作るべきプロダクトを考えよう趣旨のセクションでした。

私の汚い字が咲き乱れていますが、みんなで課題や野望を書いたボードです。

残念なことにここまでで時間切れになってしまい、肝心の議論自体ができなかったのですが、 レコメンドとコミュニティに関する要望・要求が多かったので、そこを踏まえたプロダクトの需要がありそうですね。

個人的には、面白かった作品を勝手に覚えておいて貰いたいというアイディアが面白かったです。 確かに、お奨めを聞かれても記憶の引き出しからサッと引き出してくるのは難しかったりするので、 何らかの手があるといいですね。

今振り返って考えてみると、コンテンツと人をどう繋げていくかが根本課題として横たわっているなぁ、と感じます。 商用コンテンツである以上、当たり前のことではあるのですが、 改めてITの観点からここにうまく取り組んでいきたいなと思いました。

総評

楽しかったという声も頂けたので開催できて良かったなと思いましたが、 個人的には反省点の方が多かった会になってしまったかなという感じです。

なにより進行がグダってしまったのが、一番の反省点ですね。。
最初から最後まで、積極的にファシリテートというかタイムキーピングすればよかったなと反省しています。

もっと次はチンチン鳴らせるベル持ってくるべきですね。

次回以降の改善内容に反映していければと思います。

ちなみに次回は7月頃を予定しており、もしかしたら参加費は必要ないかもしれません。
夏コミの原稿に余裕がある方は、ぜひご参加ください。

では、お疲れ様でした。

【logrotate】CentOSでログローテする

ログローテはたまにやろうとすると、あれどうだっけ？となるので logrotateを使ったログのローテーション方法をまとめました。

前提

• 環境（OS）：CentOS 6.6
• 利用機能：logrotate、cron

今回は、ローテーションしたいログ、例えばアプリケーションログを /var/log/app配下に吐いているとして考えていきます。

※作業はsudoユーザで実施してください。

手順

/etc/logrotate.dディレクトリにappファイルを作成し、ログローテ設定をします。

なので、まずはこのディレクトリをlogrotateが読むようになっているかを確認しましょう。

logrotate.dの読み込み確認

logrotate.confに以下の記述があること確認してください。
もしなければ、適当な位置に追記をしてください。

• /etc/logrotate.conf

include /etc/logrotate.d

これが設定されていれば、logrotate.dディレクトリの設定も読み込まれます。

ローテーション設定の記述

logrotate.dディレクトリ配下にファイルを作ってローテーションの設定を記述します。 ファイル名は何でもよいのですが、logが作成されるディレクトリ名など、 何のログのローテーション設定が書かれたものか分かるように様な名前が良いです。 （ここではlogディレクトリ名からappという名前にしています）

appファイルについて

• /etc/logrotate.d/app
• 権限：644、root:root

/var/log/app/*.log {
    copytruncate
    daily
    rotate 30
    compress
    missingok
    ifempty
}

以下の流れで実施すると、設定確認まできてGOODです

cd /etc/logrotate.d/
sudo vi app
logrotate -dv app

※エラーが出たら設定を見直してください。

cronの設定確認

ローテーションの設定自体は終わっているのですが、 一応cronでlogrotateが動かされているかを確認しておきましょう。

確認ポイントは、# service crond statusの結果がrunningになっていることと、 /etc/cron.daily/logrotateが存在していることです。

もしlogrotateファイルがなければ、権限：755で、root:rootの所有となるlogrotateファイルを、 以下の内容で作成してください。

#!/bin/sh

/usr/sbin/logrotate /etc/logrotate.conf >/dev/null 2>&1
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0

まとめ

これで一旦ローテーション設定は有効になったと思います。 設定内容の詳細については、appの設定値とlogrotateの詳細を参照してください☆

php-fpmはgraceful restartしません（回避策あり）

php-fpmはgraceful restart. そう思っていた頃が私にもありました

以下の公式ドキュメントに「緩やかな (graceful) 停止/起動 機能を含む高度なプロセス管理」と記載があるので、 何の疑いもなくservice php-fpm reloadを叩いたらプロセスが落ちました。。

PHP: FastCGI Process Manager (FPM) - Manual

reloadもrestartも終了処理は同じ

もちろんこれはreloadだからというわけではありません。 reloadもrestartも、実行するkillコマンドにUSR2オプションは付いています。

付いているのですが、これが期待する動作（プロセスの処理が終了したらkill）になりません。

ググるとすぐ出てくるのですが

以下のバグとして上がっていますが、ずっと放置されているようです。

PHP :: Bug #60961 :: Graceful Restart (USR2) isn't very graceful

対策

php-fpmのprocess_control_timeoutを、デフォルトの0からコネクションタイムアウトの設定値と同程度の値に変えると、 プロセスの終了を待って再起動するようになります。（reloadも同様）

おそらくこうすることで、親プロセスが子プロセスの状態を知ることができるようになるからだとは思いますが・・・推測です。 性能影響も図れていないので、これが正しい対策なのかはなんとも言えません。 ただこうするとgracefulにはなったので、課金のような途中で殺すとまずいAPIなどは、設定すると幸せになれるかもしれません。

後は、世のPHPマスターに期待するだけの人生を送ろうと思います。