Thanks Driven Life

日々是感謝

Emacs の mode-line に寿司が流れる日

f:id:gongoZ:20161123231328g:plain

未完です

未完のため、ひとまず Gist に貼ってます。

https://gist.github.com/gongo/c51ac79c1669bd71714b601b42c3be18

どのあたりが未完かというと「複数バッファを開いている時」です。

buffer A buffer B issue
sushi-bar other buffer B に移動すると buffer A で作られた timer が動いてるので「お前んとこ conveyor 空っぽだな?」って言われる
sushi-bar sushi-bar run-at-time が2重に呼ばれるので寿司の速度が2倍になる

いろいろとやりようはありそうだが、ひとまず寿司が耐えず流れてくる様を見れたので満足した。 気が向いたら正式リリースしたい。

ちなみに

「寿司の絵文字表示されねーぞ」という方は

ここらへんの設定を真似したり使ったりするといけると思います。多分。

Be inspired by

go-airplay を AppleTV 4G 対応してた

Support AppleTV 4G by gongo · Pull Request #7 · gongo/go-airplay

AppleTV 4世代目が発売されてもうすぐ1年ですが、なんかようやく手をつけたみたいな感じです。

実は 4G が出た当時は、特に修正することもなく動いててよかったねーって思ってたんですが、 何度かシステムアップデートが行われた結果、 /playback-info が返す値の中の一部の型が変わっていた、という事態でした。

とりあえず今回は

switch t := info.ReadyToPlayValue.(type) {
case uint64: // AppleTV 4G
    info.IsReadyToPlay = (t == 1)
case bool: // AppleTV 2G, 3G
    info.IsReadyToPlay = t
}

client.go#L218-L223

こんな感じで凌ぎました。きっと大丈夫です。

終わり

TravisCI 上で「(GNU, BSD) sed & 各 shell」の組み合わせでテストする

成果物

雰囲気こんな感じです。

github.com/gongo/tpdiff/.travis.yml

経緯

gongo.hatenablog.com

  1. 先日書いた sed を、せっかくなので GitHub に置いておこう
  2. せっかく GitHub に置くのだからテストでも書こう

というところから始まりました。

https://github.com/gongo/tpdiff

さてテストを書くぞ!といったところで、何を重点的に見れば良いか:

  1. 使用する shell も人それぞれ違うはず
  2. sed には GNU 版 と BSD 版がある

この2点が特に注意すべきところと考えました。

1番に関しては「POSIX 準拠かどうか」みたいなのを ShellCheck を用いて確認はしているのですが、 やっぱり実際に動作した結果を見たいという気持ちがあります。

2番については、ユーザの使用マシンが Linux だったり OS X (macOS) だったりで sed にも違いが出てくるはずなので、ここも気をつけないといけません。

TraviCI ではこうしました

上記の注意点を踏まえ、TravisCI でテストを実行してもらうために

  1. 実行環境を Linux(Ubuntu) と OS X の2つを指定する
  2. テストしたい Shell をテスト前にインストールする

こんな感じにしました。

os:
  - linux
  - osx

env:
  - SH=mksh
  - SH=dash
  - SH=bash
  - SH=zsh

BSD sed が (TravisCI が用意する) Ubuntu 環境に簡単に用意できれば話は早かったのですが、なかなか難しそうだったので BSD sed を標準で持つ OSX 環境を用意してもらうことで、そこを補うことにしました。

refs: The Build Environment - Travis CI

env に定義したテスト対象のシェル選定理由なんですが、まあ特にこれといった理由はないんですけど、これぐらいカバーしてればいいかなーと。

ちょっとした問題点

TracisCI で OS X を使用すると、さすがに起動が遅くて全体的なテスト実行時間はそこそこ掛かってしまいます。

例えば https://travis-ci.org/gongo/tpdiff/builds/156956287 を見ると

> Elapsed time 21 min 12 sec
> Total time 3 min 51 sec

テストそのものの実行時間は短いのですが、環境を用意するのも併せると 20分ぐらい掛かっているのがわかります。 まあいいかってことで今は気にしてないです。

まとめ

どなたか UbuntuGNU/BSD sed を用意できる方法知りませんか

参考

Pokemon-Emacs 〜あなたが Emacs で開いているファイルに潜んでいるポケモン〜

TL;DR

f:id:gongoZ:20160715135904p:plain

https://github.com/gongo/pokemon-emacs

経緯

最近は Pokemon Go が流行っているようで、正式サービス開始を待ち望まれているようです。

『Pokémon GO』は、位置情報を活用することにより、現実世界そのものを舞台として、ポケモンを捕まえたり、交換したり、バトルしたりするといった体験をすることのできるゲームです。 このゲームはモニターの中だけで完結せず、プレイヤーは実際に家の外に出てポケモンを探したり、他のプレイヤーと出会ったりしながら楽しむことができます。

面白そうですね。海外でも既にユーザが爆発的に増えており、スマホ片手に街をうろうろする様子などを画像や動画でも目にします。

さて、日本は夏まっさかりであり、暑い日が続いています。そんな中

「私もポケモン探しにいきたいけどまだサービス開始してないし、 そもそも外に出たくない…

という Emacs 使いも多いと思います。

でもよく考えてみてください。ポケモンは何も外だけに居るわけじゃないんです。 昔はゲームボーイにいました。じゃあ Emacs にも居るかもしれないですよね。

Pokemon-Emacs とは

https://github.com/gongo/pokemon-emacs

Emacs のマイナーモードの一つです。効果としては「今開いているファイル名の絶対パス(もしくはバッファ名)で一意に決まるポケモン名を表示する」だけです。

とりあえずいろいろがんばってインストールしてもらったあと

M-x pokemon-emacs-mode

を実行すると、(おそらく)ファイル名の横あたりに、下図っぽい感じでポケモン名が表示されます。

f:id:gongoZ:20160715133107p:plain

この場合は ナッシー が選ばれました。

つまり /Users/gongo/src/github.com/gongo/pokemon-emacs/README.md にはナッシーが潜んでいる。豆知識です。

ちなみに *scratch* にはナゾノクサが居ます。多分。

実装についてちょっとだけ

特に難しいことはしてませんが

  1. ファイル名、もしくはバッファ名を seed として乱数をゲット
    • なのでどの環境でもファイル名が同じ = 同じポケモンが出てくる。はず。
    • (もちろんポケモン一覧 pokemon--monsters が変化したら変わりますが…)
  2. ポケモン一覧から↑の乱数を index としてポケモンをゲット

これだけです。

少し前に Pokemon-Go におけるポケモン出現率*1 みたいな画像を見たので、出現率に併せて「出やすいポケモン」「出にくいポケモン」みたいな実装をしてたんですが、 あの画像自体デマだったみたいなコメントもあったので、まあいいかってことでとりあえず愚直にリストから取るようにしました。

あとはポケモン一覧はとりあえず初代の 151 匹*2をチョイスしました。他のシリーズ追加すれば勝手に出てくるとおもいます

まとめ

/path/to/fooピカチュウが潜んでいたぞ!!」 「ミュウが見つからねえ!!」

みたいな楽しみ方で、エディタ生活に華を添えてください。ポケモン大好き!!

Docker Image がデプロイできるようになった Heroku で、Emacs (elnode) on Alpine Linux を動かす

成果物

(7/21 追記: Docker Hub のリポジトリ名を gongo/docker-emacsgongo/emacs に変更しました)

経緯

Container registry public beta - deploy Docker images to Heroku | Heroku Dev Center


半年ほど前に heroku-docker を使ってみた んですが、 今回の発表は更に熱くて、まさに Docker Image そのものを Heroku にもっていけるということで、早速試してみました。

作成した Docker Image

今回は Alpine Linux をベースに、Emacs や Cask に必要なライブラリ(python など)をインストールしています。

デプロイしてみる

Container Registry and Runtime | Heroku Dev Center の手順通り。 今回はあらかじめ docker build して動作確認したりしていたので、いざデプロイする時には「Pushing an existing image」を行いました。

$ heroku apps:create gongo-docker-emacs
$ docker tag gongo/emacs:example registry.heroku.com/gongo-docker-emacs/web
$ docker push registry.heroku.com/gongo-docker-emacs/web 

そして出来上がったのがこちら(いつか消します)

https://gongo-docker-emacs.herokuapp.com/

まとめ

お手軽感が高いです。 いくつか制限はある らしいですが、まだ Beta ですし、正式リリースされたら解決するかもしれないので、そこらへんはゆったり待ちましょう。

そんなわけでみなさん Emacs を動かしましょう!!

terraform plan の実行結果で、属性値が変更になる行に色付けする sed

TL;DR

readonly escape_ansi=$(printf '\033')

sed -e '/".*" => ".*"$/!b' \
    -e '/^.*: *"\(.*\)" => "\1"$/!s/.*/'"$escape_ansi"'[31m&'"$escape_ansi"'[m/'

f:id:gongoZ:20160702110516p:plain

経緯

毎晩暑い日が続く日本、AWS の各種リソース管理を Terraform で行っている皆様におかれましては、 日々の業務において terraform plan をよくお使いになられていることと存じます*1

そんな中、例えばこのような実行結果が表示されたとします:

..
.. (message)
..

+ aws_security_group.app
    ingress.#:                   "" => "1"
    ingress.0.cidr_blocks.#:     "" => "1"
    ingress.0.cidr_blocks.0:     "" => "192.0.2.0/24"
    ingress.0.from_port:         "" => "80"
    ingress.0.protocol:          "" => "tcp"
    ingress.0.to_port:           "" => "80"

-/+ aws_security_group.db
    ingress.#:                   "2" => "2"
    ingress.0.cidr_blocks.#:     "1" => "1"
    ingress.0.cidr_blocks.0:     "198.51.100.0/24" => "198.51.100.0/24"
    ingress.0.from_port:         "3306" => "3306"
    ingress.0.protocol:          "6" => "tcp"
    ingress.0.to_port:           "3306" => "3306"
    ingress.1.cidr_blocks.#:     "" => "1"
    ingress.1.cidr_blocks.0:     "" => "203.0.113.0/24"
    ingress.1.from_port:         "" => "5432"
    ingress.1.protocol:          "" => "tcp"
    ingress.1.to_port:           "" => "5432"

-/+ aws_security_group.mail
    ingress.#:                   "2" => "1"
    ingress.0.cidr_blocks.#:     "1" => "1"
    ingress.0.cidr_blocks.0:     "198.51.100.0/24" => "198.51.100.0/24"
    ingress.0.from_port:         "587" => "587"
    ingress.0.protocol:          "6" => "tcp"
    ingress.0.to_port:           "587" => "587"
    ingress.1.cidr_blocks.#:     "1" => ""
    ingress.1.cidr_blocks.0:     "198.51.100.0/24" => ""
    ingress.1.from_port:         "995" => ""
    ingress.1.protocol:          "6" => ""
    ingress.1.to_port:           "995" => ""

Apply complete! Resources: 1 added, 2 changed, 0 destroyed.

(実行結果はてきとうです)

各セキュリティーグループのルール数が2、3個なのでまだまだ見えますが、例えばルール数が20個とかになるとかなりの行数が目に入ります。その中で どの行(属性)が変更なのかぱっと見、わかりづらい と思うわけです。思いました。

まあそんなわけで、属性値に変更のある場所がわかりやすく見えればいいな、ということで、いくつか方法はあると思いますが、今回は sed でやってみました。

sed

readonly escape_ansi=$(printf '\033')

sed -e '/".*" => ".*"$/!b' \
    -e '/^.*: *"\(.*\)" => "\1"$/!s/.*/'"$escape_ansi"'[31m&'"$escape_ansi"'[m/'
  1. "xx" => "yy" という文字列(xxとyyは任意)を 含まない 行はスキップして次に進む
  2. "xx" => "xx" という条件に一致しない(つまり左と右の "" 内の値が 同じではない )場合 に、赤で色付けする

こんな感じでできました。パターンは単純なんですが terraform plan の実行結果に対してだけ使うのであれば充分かなと思います。

ついでにこいつをスクリプトに落とすと、雰囲気こんな感じ

#!/bin/sh

readonly escape_ansi=$(printf '\033')
readonly program_name=$0

if [ -p /dev/stdin ] ; then
    cat -
else
    if [ ! $# -ge 1 ] ; then
        echo "$0: [ERROR] You must specify file."
        exit 1;
    fi

    if [ ! -f "$1" ] ; then
        echo "$0: [ERROR] \"$1\" No such file."
        exit 1;
    fi

    cat "$1"
fi | sed -e '/".*" => ".*"$/!b' \
         -e '/^.*: *"\(.*\)" => "\1"$/!s/.*/'"$escape_ansi"'[31m&'"$escape_ansi"'[m/'

てきとうに tpdiff とか名前で保存しておいて

$ terraform plan | tpdiff

こんな感じで、冒頭の画像のように表示されます。多分。

ひとまず

あたりでは動いているようです。

まとめ

sed 難しい

おまけ

当初、sed の色付けする部分を

-e $'/^.*: *"\\(.*\\)" => "\\1"$/!s/.*/\e[31m&\e[m/'

みたいな感じでやってたんですが、 POSIX 準拠してるかってチェックしてくれる shellcheck を使うと

fi | sed -e '/".*" => ".*"$/!b'
         -e $'/^.*: *"\\(.*\\)" => "\\1"$/!s/.*/\e[31m&\e[m/'
            ^-- SC2039: In POSIX sh, $'..' is undefined.

ってな感じで怒られたので、printf 使うようにしました。

*1:手元実行なんかせず、Atlasにお任せしてる人が多いのかもしれない