サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
iyuichi.hatenablog.jp
Botkitを使ってボットを作っていました。 ボットでチャンネルに常駐してBuild successというメッセージがきたら ダウンロードリンクを取得 QRコードの画像ファイルを作成 作成した画像ファイルをSlackに投稿 だいたいこんなことをやりたいボットです。 QRコードを作るのは簡単で以下のモジュールを使ってすぐに実装できました。 GitHub - soldair/node-qrcode: node js server side qr code generator utilizing node-canvas 使い方はこんな感じ。 var QRCode = require('qrcode'); QRCode.save('./qr.png' , 'http://google.com', function(err){ if(err){ console.log(err); } }); さて作
今回、サイトマップから取得したURLの中からランダムに選んだ記事のURLとタイトルをTwitterでつぶやくアプリを作って見ました。 最近なんだかNode.js書くのが楽しいのでNode.jsで実装しています。 Nodeクックブック 新品価格 ¥3,672から (2015/4/24 19:34時点) まず、ソースはGitHubにアップしましたので興味がある方はご覧下さい。 github.com サイトマップXMLをパースする まず、はてなブログにはサイトマップXMLが生成されています。 このブログの場合は以下です。 http://iyuichi.hatenablog.jp/sitemap.xml こいつをパースして記事のURL一覧を取得して適当に選ぶ部分を実装します。 世の中にあるものは基本利用したいのでモジュールを検索してみました。 こいつが使えそう!とおもったので利用して動かしてみまし
Slackはメッセージのエクスポートができます。 できるのは、Team OwnerかAdminのユーザです。 ただ、フリープランで利用している場合には、private channelやdirect messageはエクスポートデータには含まれません。 公開されているチャンネルが対象となります。ちょっとだけ残念。 詳細はこの辺を参照 Understanding Slack data exports – Slack Help Center では早速エクスポートをしてみます。 https://my.slack.com/services/export start exportをするとzipファイルでデータがDLできます。 回答すると、チャンネル毎のディレクトリに日付毎に分割されたjsonファイルが入っています。 それをMongoDBに入れてローカルで検索できるようにしてみました。 slackからe
サービスが置かれているデータセンターと同じ場所でZabbixやNagiosなどを動かして死活監視を実行していますが、データセンター自体のネットワークや電源のトラブルなどで監視サーバごとダメになってしまうケースがあったので外部からURL監視だけでもやっておこうと思い簡単にできる方法を調べていたところ以下の記事を見つけました。 Google Apps Script でWEB死活監視(複数URL編)dozensmembers.wordpress.com 基本はこの記事のものでも良かったのですが少し欲が出てきて、以下のような仕様を盛り込んだものを作成してみました。 スプレッドシートで監視するURLを追加、削除したい 通知先をURLごとに設定できるようにしたい URL Monitoring using Google AppsScript スプレッドシートは以下のようなものを作成します。 サービス名は
Analyzing Audit Logs Using BigQuery - BigQuery — Google Cloud Platform この辺のページを参考にしました。 BigQueryは普通に使っている分には非常に料金安くて早くて良いものなのでどんどん利用したいところです。 しかしながら、クエリの書き方によっては思わぬ高額になることもあるらしいってことで、 やたら多くのデータ量を扱っているクソクエリが現れたら検知したい! そこで使えそうなのがAudit Logs。 Audit LogsをBigQueryにエクスポートできるので、そのログを使ってクエリが検索したデータ量を集計することができます。 グーグルのサンプルはドルに換算していましたがクソクエリを探してチューニングするためにはデータ量で充分なので以下のようなクエリを書いてみました。 過去7日間で最も費用がかかったクエリを抽出する
Google Cloud StrageはGoogleが提供するAmazonのS3みたいなものです。 こいつに接続するためにコマンドラインのツールが提供されているので利用してみます。 以下のページでインストール方法などは見られます。 Developer Tools - Tools — Google Cloud Platform 最初、試してみるときには gcloud auth login としてブラウザが起動してGoogleアカウントでログインする方法でやってました。 それでも良かったのですが、管理画面をみていたら APIと認証->認証情報->新しいクライアントIDを作成 とするとAPIアクセス用のサービスユーザの作成ができるようなのでそちらでやってみよう!と思ったら軽くハマりました。 サービスIDを使ってgsutilを動かす まずは以下の画面で新しいクライアントIDの作成を押します。 する
FQ5というKPIをご存知でしょうか? ソーシャルゲーム界隈ではおなじみの連続ログイン5日のユーザIDやその数を集計して、キャンペーンやイベントの成果を計測したりするために参照します。 ある日のDAUを連続ログイン5日、4日、3日、2日、1日と各ユーザ数にわけて数字を集計するのですがこいつをFQ5と呼びます。 ちなみにFQの定義を連続ログインではなくて、直近5日間のログイン回数と定義してたとえば以下のように1日おきとか間をおいて遊んでくれているユーザもFQ3とカウントしてよい場合にはもう少し簡単なクエリにできます。 今日 昨日 2日前 3日前 4日前 ◯ × ◯ × ◯ ◯ × × ◯ ◯ ◯ ◯ × ◯ × 今回紹介しているクエリは"連続"のみをカウントするものです。 FQ3であれば以下のパターンのみが該当するように集計します。 今日 昨日 2日前 3日前 4日前 ◯ ◯ ◯ × × ◯
Heroku | New Dyno Types and Pricing Public Beta Heroku使ってますか? わたしは、いくつかNode.jsで自作したボットとか動かして楽しんでいます。 最近、会社でもslack連携させるhubotをherokuを使って運用するのを試しています。 そんな中で新料金が発表されました。 ざっと目を通していたら気になる点が。 Awake time max 18hrs/day 1日18時間までしか起動させておけなくなるようです。 heroku schedulerとか、監視サービスとか利用してHack的にDynoを寝かさないようにしている方、結構いるんじゃないでしょうか。 自分もHubotをhubot-heroku-keepaliveというモジュール使って起こし続けているのですが、それができなくなりそうです。 でもよく考えてみると、起きていてほしい時間
How to check SHAハッシュはデータが正しいか確認するのによく使われる手段かと思います。 方法は簡単です。shasumというコマンドがあります。 shasum /path/to/file これで取得できるハッシュ値はsha1ハッシュです。 The default for the shasum command is to use SHA1. アルゴリズムは、-a オプションで変えることができます。 But this can be changed with the -a flag if necessary. -a, --algorithm 1 (default), 224, 256, 384, 512, 512224, 512256 たとえば、sha256で検証したい場合は、以下のように指定します。 shasum -a 256 /path/to/file ちなみに、sha1がmd5
削除は論理削除にしたいのでググったらacts_as_paranoidというプラグインがメジャーっぽかったので試してみる。 まずはプラグインをインストール。 $ gem install acts_as_paranoid削除日付を入れるカラムを追加。 ModelNameのところは実際のモデル名を記述。 $ ruby script/generate migration AddDeletedAtToModelName deleted_at:datetimeDBマイグレーションして、 $ rake db:migrateモデルに acts_as_paranoid を追記 class ModelName < ActiveRecord::Base acts_as_paranoid # 論理削除プラグイン用 has_many :sub_items, :dependent => :destroy : (以下、
参考になったのでメモ代わりに。 SHOW STATUS を解析した結果で、Handler_read_rnd_next の値が とても大きくて、その解析からINDEXの解析をすることになった。 「Handler_read_rnd_next」は、 こちらINDEXとクエリ調査の必要がある値。 INDEXが正しいのか調査するのに、下記の値もある。 → SHOW STATUS ・ Handler_read_rnd_next □このカウンタの値が大きいとインデックスを活用できるように、クエリの調整が必要。 ・ Select_full_join □値が 0 でなければ、インデックスの調査が必要 ・ Select_range_check □値が 0 でなければ、インデックスの調査が必要 ・ Sort_scan □値が多いと、インデックスの調査が必要 SLOW LOGの設定でも、 □log-long-fo
eclipseでは何の問題もなくコンパイルされているソースが、mavenでビルドするとBUILD FAILUREとなる現象にちょっとはまりました。 こんな警告が出ます。 「○○ は Sun が所有する API であり、今後のリリースで削除される可能性があります。」 jdk5を使っているときは特になんの問題もなくビルドできていたのですが、jdk6にしてみようとしたら。。でした。 で、結果としてはrt.jarを明示的にコンパイル時のbootclasspathに設定してやったらビルドができるようになりました。 Now your code is relying on a Sun internal class and not a base JDK class. The appropriate classes exist in the $JAVA_HOME/lib/rt.jar file. Unfor
このページを最初にブックマークしてみませんか?
『iyuichiの私的開発ログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く