ぐるっとぐりっど

日曜プログラマがいろいろ試してみたことを、後の自分のためにまとめておく場所

Slackとorg-modeを連携したかった話

Slack Zapier emacs

情報収集してますか？


これまでrssリーダ使ってたのも未読がたまってしまい鬱陶しかったので、rssをslackに移行するだけの個人Slackに今は切り替えてます。
ただ、rssのころもそうでしたが、後でよむ的操作と、保存しておきたい操作が、slackの場合難しいです。個人Slackなんだから、pinでもなんでもすりゃいいんだけど、再集約は別の場所にしたい。無料版だとslack、メッセージ数に制限があるしね。

iftttとzapier

というわけで、スターをつけたメッセージに対し、なにかしらしたかった。

そういう用途であれば、iftttとzapierあたりがあげられます。気にはなってたけど、これまで使ったことなく、必要性を感じることもこれまでなかったのですが、遂に使うことに。

で、結論ですが、zapierを使うことにしました。理由は明快で、スターをつけたメッセージをトリガーとすることが、iftttではできなかった。iftttは何らかのトリガーでslackに投稿することはできても、slackをトリガーとすることは現状できなかったのです。
あと、MicrosoftもFlowとかいうのを最近出したようですが、これもslackをトリガーとすることはできないらしい。
zapierの懸念としては、無料プランだと、月100回までしかタスクを実行できないらしい。せっかく作成したばかりだけど大丈夫かな？

スターをつけたメッセージをトリガーにする

というわけでzapierであります。

zapierではこういった処理のことをzapと呼んでいて、「Make a zap」ボタンで簡単に作ることができます。試しにSlackでスターをつけたメッセージを、後で読むサービスのPocketに投入する、というのを作ってみたら、ポチポチするだけで簡単に作れてしまいました。超簡単。

f:id:grugrut:20170625094352p:plain

org-modeとの連携

さて、前置きがかなり長くなりましたが、org-modeとの連携です。私は、org-modeで使っているorgファイルを、DropboxでスマホやPC群で共有しています。
zapierのインテグレーションを見ていると、Dropboxがあり、インテグレーションの動作に「Append Text File」というのがあったので、これでできるのでは？ とやってみることにしました。
設定はこんな感じ。

f:id:grugrut:20170625094252p:plain

結果

f:id:grugrut:20170625095011p:plain

まあ、設定画面にそんなこと書いてあったので、嫌な予感はしてたのですが、勝手に拡張子.txtを追加されてしまいました。.orgって拡張子自分でつけてるのに。
ただ中身を見てみると
f:id:grugrut:20170625095801p:plain
という感じで、ちゃんと複数行にわたって追記がされているので良いかんじ。

拡張子を変える方法があればもっとよくなるのに、この悲しみはどこに伝えるのがよいのだろうか。

そろそろWSLメインで開発できるかと思ったけど、まだまだ辛さが残る

Linux Windows emacs WSL

ポエムです。

来る2017/4/11にWindows10のCreators Updateがきて、WSL（Windows Subsystem for Linux/BoW/BoUoW/Bash on Ubuntu on Windows）も色々と強化されました。
で、これまでmsys2でemacsだったりnodejsなり動かしてたのだけども、ちょくちょくWindowsの世界に乗り込んでいかねばならないせいで、いろいろとつらみが高まってたので、これを機に開発はWSLに全部投げれないかなと試しに数日使ってみました。

おとなしくmacなりlinuxなりにすればいいじゃないって？ ゲーム（steam）もしたいじゃない。

辛さ

emacs

WSLにはXサーバはないので、GUIのemacsを使うには、何とかする必要がありました。自分はxmingを使ってます。タスクバーのアイコンがxmingのそれになってしまう以外は、特に不満はなし。
フォントがなんか小さくなってしまう場合は、xmingの起動オプションに-dpi 100をつけてやればよいみたい。

辛さとしては、emacs &で起動してinit.elを読んでる間に、Bashの操作をすると、emacsを巻き込んでBashが落ちる。
Bashとemacs両方にstraceしてみた感じだと、Bash側でシステムコールに失敗してるっぽいのだけど、細かい原因は不明。

phantomjs

なんかスクリーンが見つからない的なエラーをはいて落ちる。そもそもphantomjs自体使ったことなくて、たまたまcontributeしようとしたプロジェクトがテストに使ってたのを見よう見まねで動かしただけなので環境構築ミスなだけかも。

Electron

こちらも起動すると、xmingの画面が表示されるもクラッシュしてしまう。issueとしては上がってるぽいので今後に期待。
ちなみに、msys2上でnpm installしたelectronは動いて、WSLで改めてnpm installしてみたらダメだった。Windowsとのシームレスな運用ができるってことですねニッコリ

2017.9.8追記

ビルド16275で、electronが動作するように改善されました。

grugrut.hatenablog.jp

ありがたみ

つらみだけだとアレなんで、ありがたみも

プロセスの扱い

msys2だと、Windowsに入れたGoを起動すると、psしても見ることができず、わざわざタスクマネージャから殺す必要があったのに対して、WSLだとpsできちんと見える（ような気がする）。

ホームディレクトリ

WSLはファイルシステムが独立してるので、Windowsから変更するとファイルが壊れてしまうらしい。
ところがどっこい、vipwでホームディレクトリを/mnt/c配下の適当なフォルダをホームディレクトリにして、WindowsからもWSLからも変更できることが確認できた。
さすがに/etcとかは無理だけど、その辺メモ帳で変更したい要件などないから問題なし

まとめ

現時点ではつらみが多いけど、議論も開発も活発だと思うので、切り捨てるには時期尚早

ELKスタックの後継なるか、influxdbのTICKスタックをさわってみた

Linux Telegraf InfluxDB Chronograf Kapacitor

結論から言ってしまうと、ならない。
というかそもそもELKスタックか目指してるものとは別物でしょ。どちらかと言えば、re:dashとELKスタックを比べるべき。なのでここからはTICKスタック単体の話です。

まだ半日ぐらいしかいじってないので、感想は後々変わるかも

TICKスタックとは

時系列データベースのinfluxdbでお馴染みの、influxが出しているログを収集して活用するための一連の製品群とその構成。
Telegraf、InfluxDB、Chronograf、Kapacitorからなり、それぞれ以下の役割を担っている。

  • Telegraf
    • InfruxDBをはじめとする時系列DBへの挿入に特化したコレクタ。InfluxDBだけでなく、PrometheusとかGraphiteとか、もろもろのものにつっこめるようになってるらしい。CPU使用率等のシステムリソースを収集できるように初期設定されていて、設定を有効化するだけで、InfluxDBにつっこめる。
  • InfluxDB
    • 時系列DB。RESTでデータを簡単につっこめて、SQLライクな構文でデータを取得できる。
  • Chronograf
    • 収集したデータを可視化するためのWebダッシュボードを提供する。以前は、InfluxDBのデータの可視化はGrafanaが担当してたと思うけど、自前でもいつのまにか作ってたのね。見た目はGrafanaにかなり似ていて、折れ線グラフしか表示できないところもかわらない。Kibanaみたいに柔軟な表示ができればもっと嬉しいのだけども。
  • Kapacitor
    • 収集したデータに関して、監視し、トリガーでアラートを出せるらしい。TICKスタックさわってみたといいつつ、これは特に触ってない。

https://www.influxdata.com/products/open-source/

目的

もともとVPS一台運用だったので、たいした監視は必要なかったんだけど、リソースに余裕があるかは把握しておきたかった。ただ、一時期ELKスタック(正確には、fluentdを使ってたのでEFKスタック)も使ってたけど、どうしてもElasticsearchがメモリをバカ食いするせいで、1台運用には荷が重すぎて、muninを使ってた。ただ、muninは今は表示できても、複雑な計算は苦手なので、もうちょっとパワーのあるやつが欲しかった。

最近だと、re:dashあたりがはやってて、「re:dashは軽量なので、AWSのmicroインスタンスでもいけるよ」、と聞いていたので期待してたのだけど、さすがに他の機能ももたせたサーバで動かすのには苦しい(1Gぐらいはメモリをどうしても食ってしまう。VPSだとメモリがいちばんコストに響いてくるので、1Gはきつい)ということもあり、もうちょっとシャレオツかつ軽量のもので、リソースを可視化できるようにしたかった。

インストール

https://portal.influxdata.com/downloads
を参照のこと。各OSごとにインストール方法が記載されてる。

自分の環境はCentOSだったので、たとえば

# yum install https://dl.influxdata.com/telegraf/releases/telegraf-1.2.1.x86_64.rpm
# service telegraf start

などとするだけだった。

CentOSの場合は、/etc/telegraf/telegraf.confにTelegrafの設定ファイルができるので、必要に応じてコメントを解除

# [[inputs.nginx]]                       ← コメント解除でnginx情報の収集有効化
#   ## An array of Nginx stub_status URI to gather stats.
#   urls = ["http://localhost/status"]   ← nginxのステータスページのURLに変更

とするだけで簡単に収集することができた。また、CPU使用率のような一般的なものは自動で収集してくれる。

そして、収集後、Chronografにアクセスすると、こんな感じでおしゃれにグラフ表示してくれる。

f:id:grugrut:20170429224611p:plain

InfluxDBなんで、期間内の最大値とか平均値とか、微分とかいろいろ出してくれるはずだけど、そこまではまだ手を出していない。
TICKスタックは、golangで書かれていて、プラグインも作りやすそうなんで、せっかくだからなんか作ってみたい。

さわってみて

クエリをWebで簡単に構築できて、自分のダッシュボードを作れるというところがよい。なにより軽量(現時点では、300Mバイトぐらいしか消費していない)のがよい。本当はKibanaのようにGeoIPを使って、地図で表現できたりするともっと良いのだけども。。

これまで、InfluxDBは数値データを格納するためのデータベースと誤解してたけど、どうやらテキストデータも入れれて検索もできるらしいので、そちらも今後収集してみたい。(以前使ったときは0.7.0ぐらいだったので、いろいろと進化しててびっくり。Webインタフェースも最近なくなってしまったみたいだし)

keyfreq.elでEmacsのキーバインドを効率良く使えているか振り返る

emacs

はじめに

人の.emacs.elを読んでたり、パッケージを漁ってたりすると、これいいじゃんって設定やイケてるキーバインドがいろいろと出てきます。そうするとやはりマネするというか自分のにも取り込みたくなるのが人情というものですが、はたして設定したっきりになってないでしょうか。

keyfreqは、emacsのキーバインドの利用状況を記録して振り返ることができます。
(といいつつ、実際のところはコマンドの実行状況ですが)

github.com

MELPAに登録されているので、

M-x package-install keyfreq

するだけで簡単に導入可能

使いかた

上記レポジトリに書いてある通りですが、

(require 'keyfreq)
(keyfreq-mode 1)
(keyfreq-autosave-mode 1)

するだけ。

で、普通に使っていて、気になったときに

M-x keyfreq-show

すると、以下の感じで使ったキーバインドの統計情報(というか集計情報に近いかも)が表示されます。

f:id:grugrut:20170412173925p:plain

自分の場合、next-line使いすぎなので、C-vとか、ちゃんと使おうよ、って思える結果に。

あと、avyせっかく導入してみたのに、全く使ってないことがわかってしまった。

キーバインドを設定したいけど、かぶってて、、、という場合なんかにも、「でも実際のところ使ってないじゃん」というのがわかる、あるいは毎度毎度M-xしてるのであれば、キーバインド設定してもよかない？というのがわかるので、非常におもしろいパッケージだと思います。

問題点

BUGとしてissueにも登録されてますが、複数のemacsを起動したときにファイルロックが競合してうまく動かない(記録できないだけで実害は無いがロックかかってるよってメッセージがうっとうしい)のが難点。emacsclientで複数の場合にどうなのかは不明。

Jenkinsでgo言語のプロジェクトをCIする方法を調査した

golang jenkins

はじめに

Golangをちまちまプライベートで触っていて、バックエンドサーバを試しにgolangで書いてみてるんだけど、Jenkinsのpipelineでgoを扱う方法が、調査しても断片的にしか出てこなかったので、本腰を入れて調査してみた。
pipelineでなければ、もっと簡単そうだけど、BlueOceanも1.0リリースされたしね。

みんなのGo言語【現場で使える実践テクニック】

みんなのGo言語【現場で使える実践テクニック】

対象

ソースコードはこちら

github.com

単なる足し算を実装しただけの簡易なもの。
しかも明らかにミスってる(もちろんわざと)

func Sum(a int, b int) int {
	return a + a
}

これをJenkinsでTestしてみる。

事前準備

プラグインの導入、初期設定

Go pluginを導入しておく

Go Plugin - Jenkins - Jenkins Wiki

次にプラグインの設定をする。
日本語メニューの場合、「Jenkinsの設定」→「Global Tool Configuration」にGoの設定があるはず。(http://JenkinsのURL/configureTools/ にアクセスしてもよい)

インストール済Goというのに適当な名前(ここではGo1.8とした)をつけて、必要なGoのバージョンを設定しておく。これは必須ではないが、これをやっておくと、Jenkins専用のGoを設定しておくことができる。CentOSのepelリポジトリが1.6までしかなくて、depが使えなかったので、このやりかたで導入した。

f:id:grugrut:20170410195400p:plain

Jenkinsfileを書く

pipelineは、Jenkins上で書くこともできるけど、ファイルとして切り出して管理することもできる。バージョン管理もできるし、そちらの方が推されてるはず。

というわけで、Jenkinsfileをごりごり書いた。

書いてみたのがこんな

node {
    def root = tool name: 'Go1.8', type: 'go'
    ws("${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_ID}/src/github.com/grugrut/golang-ci-jenkins-pipeline") {
        withEnv(["GOROOT=${root}", "GOPATH=${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_ID}/", "PATH+GO=${root}/bin"]) {
            env.PATH="${GOPATH}/bin:$PATH"
            
            stage 'Checkout'
        
            git url: 'https://github.com/grugrut/golang-ci-jenkins-pipeline.git'
        
            stage 'preTest'
            sh 'go version'
            sh 'go get -u github.com/golang/dep/...'
            sh 'dep init'
            
            stage 'Test'
            sh 'go vet'
            sh 'go test -cover'
            
            stage 'Build'
            sh 'go build .'
            
            stage 'Deploy'
            // Do nothing.
        }
    }
}

重要(というか自分が詰まった)なのが前半部分。

    def root = tool name: 'Go1.8', type: 'go'

必要なバージョンのGoを利用するための設定がこちら。
nameのところに先程のプラグイン設定で名付けたものを入れる。
はじめに利用するときに、goが自動でダウンロードされるので、始めの一回はそこそこ時間がかかるけど、次からはすぐに使える。ちなみに、このGoのインストール先は、${JENKINS_HOME}/tools/org.jenkinsci.plugins.golang.GolangInstallation/Go1.8/
となっているようだ(最後のGo1.8は自分がつけた名前)。

    ws("${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_ID}/src/github.com/grugrut/golang-ci-jenkins-pipeline") {
        withEnv(["GOROOT=${root}", "GOPATH=${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_ID}/", "PATH+GO=${root}/bin"]) {
            env.PATH="${GOPATH}/bin:$PATH"

Goに入ってはGoに従えの格言の通り、Golangらしいファイル配置になるように設定している。
1行目のwsは、カレントディレクトリを設定している。普通は${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_ID}/が、カレントディレクトリになるところを、src配下に配置するようにしている。詳細は以下のページで。

Goコードの書き方 - The Go Programming Language

次に2行目は、GOROOTとGOPATHの二つの環境変数を設定している。PATH+GOで、goのバイナリの箇所を設定しているらしいけど、詳しいドキュメントが見付からず、ここは見様見真似でやってる。
GOPATH配下のbinもPATHに含めたかったのだけど、withEnvでやろうとすると、(おそらく)Jenkinsとしての変数展開と、shellの変数展開が競合してうまくいかなかったので、3行目に別途いれてる。


あとは、ソースコードの通り、チェックアウトして、depをインストールした上で、依存関係を解決、その後go vet, go testと来て、とおればbuildしておしまい。(とはいえtestでこけるのでbuildまで行かないのだけど)

結果

f:id:grugrut:20170410201344p:plain

こんな感じで、testにこけてることが確認できた。

なんとなく動いてる気はするけど、もっと効率の良いやりかたがありそうなので、ご存知の方いたら教えてください！！

書籍の情報を検索して挿入するためのHelmインタフェースを作ってみた

emacs

前回grugrut.hatenablog.jpの続き

やりたかったこと

org-modeで本の記録を取るのに、いちいち著者情報を手入力するのがきつすぎるので、検索していいかんじにバッファに挿入させたかった。
で、それを実現するのにHelmインタフェースで作るのが、それっぽいかんじで良さそうだったので、そうした。

HelmインタフェースもAnythingインタフェースも作ったことなかったので、やってみたかったというのもある

できたもの

github.com

使いかた

requireして、M-x helm-booksするといつものHelmインタフェースが表示される。
そして入力すると入力した文言に対してgoogle books apiに対してクエリが発行されて結果がリストとして表示される。

f:id:grugrut:20170320153659p:plain

Actionとしては、挿入する文章を変数"helm-books-custom-format"で設定することができる。

org-modeとの統合

org-captureでは、テンプレートに

(setq org-capture-templates
        '(("b" "book memo" entry
           (file (concat org-directory "book.org"))
           "* %(helm-books)"
          ))))

のように、%(sexp)とすることで、S式を埋め込むことができる。
これを利用することで、このテンプレートを呼び出すと、自動でhelm-booksが呼ばれ、本を検索し、必要な情報をプロパティとして設定したメモを簡単に取ることができる。

これはすごい

今後

  • ActionがInsertしかないので、他のActionを増やす
  • 情報源がgoogle books apiだけだが、検索結果が気持ち心許無いので、他のAPIからも取得できるようにする

Emacs Lispテクニックバイブル

Emacs Lispテクニックバイブル

本の情報を取得するためのHelm拡張を作ってみた(途中)

emacs

続きを書いた
grugrut.hatenablog.jp


init.el読書会で、org-modeのメモを読書記録にするための、org-captureのテンプレートがあって、やりたかったのだけど、いちいち本の情報をプロパティに手打ちするのは面倒だと思った。

例

* ゼロから作るDeep Learning 
:PROPERTIES:
:Author: 斎藤 康毅
:Year: 2016
:Publisher: オライリー
:END:

なんか皆やってそうなので、こういう情報を簡単に挿入できるような良いパッケージが無いか探してみたのだけど、みつけられなかったので、Helm拡張として作ってみることにした。

作るにあたっては、
helm拡張を書く - Qiita
Developing · emacs-helm/helm Wiki · GitHub
を超参考にした。

現状

f:id:grugrut:20170315222257p:plain

google books apiを使って、本の情報を引っぱってきている。
現状では、検索文字列が決めうち(emacs)、Actionは未定義で、候補が表示されるところまでできている。

入力するたびにAPIを呼ぶことになりそうなので、性能問題や、API呼びすぎてブロックされないかがちょっと心配

Helm拡張書いてみての感想

まだsourceの定義の一部しか終わってないけど、はじめとっつきにくい印象(公式documentもそこまで充実してないし)だったけど、ちょっとずつ書いてみたら、意外とあっさり書けた。
actionの定義はもっと簡単そうな気がするので、この調子でちゃんと完成させたい。

Emacs Lispテクニックバイブル

Emacs Lispテクニックバイブル