糸島の海

自作の Lokka プラグインに Amazon の Product Advertising API に問い合わせてアフィリエイトリンク付きの商品画像を返すやつがある。 Amazon 上の商品管理番号を <!-- ASIN=XXXXXXXX --> みたいな感じで本文中に書いとくと良い感じに小銭を稼げるかたちのリンクにして画像を表示してくれるという便利なやつ。

Amazon の規約上、 Amazon Product Advertising API に対しては一秒間に一リクエストしか送ってはいけないことになってるので、データを取得する度に 1 秒 sleep するようにしていたけど、一ページ内で複数のリンクがあるときにキャッシュがエクスパイアして Amazon の API を叩くとめっちゃレスポンス遅くなってださかったので非同期で取るようにした。ページコンテンツ本体はサクッと返して、商品情報などの取得はページがレンダリングされたあとに JavaScript で行う。 Amazon から JSON を取ってくる処理自体は Ruby にやらせる。

+----------+            +----------------+             +--------------------------------+
|          | +--------> |                | +---------> |                                |
|  client  |            |  Ruby (Lokka)  |             | Amazon Product Advertising API |
|          | <--------+ |                | <---------+ |                                |
+----------+            +----------------+             +--------------------------------+

最初は雑に body の innerHTML を正規表現で replace したりしてたんだけど、そうすると Twitter のウィジェットなど本文内に埋め込んである script タグが動かなくなる問題に気がついた。 HTML 5 の仕様で、 innerHTML = で挿入されたコンテンツの script タグは無視されるらしい。なるほど〜。

element.innerHTML - Web API インターフェイス | MDN

ということでもうちょい調べたら DOM には Node.nodeType というプロパティがあって、COMMENT_NODE など type を持っているらしい。

Node.nodeType - Web API インターフェイス | MDN

<!-- ASIN=XXXXXXXX -->COMMENT_NODE として扱われるので、こいつの後ろに document.createElementして JavaScript で動的に生成された要素を突っ込むようにした。 Promise を使ってナウでヤングな感じに書いた。

let promise = new Promise(function(resolve, reject) {
  request.open('GET', url);
  request.onreadystatechange = function() {
    if (request.readyState != 4) {
      // リクエスト中
    } else if (request.status != 200) {
      // 失敗
      reject(request.response);
    } else {
      // 取得成功
      let formatter = new Formatter(request.response);
      let result = formatter.formatItem();
      resolve(result);
    }
  };
  request.send();
});
promise.then(function(result) {
  let previous = node.previousSibling;
  let parent = node.parentNode;
  let d = document.createElement('div');
  d.className = 'amazon';
  d.innerHTML = result;
  parent.insertBefore(d, previous.nextSibling);
}).catch(function(error) {
  console.log(error);
});
return promise;

意地でも jQuery 使うまいと思ってやってみたけど意外と大丈夫だった。楽をせずに素の JavaScript を書いていると精神が浄化されるような感覚があってよい。写経に通じるものがある。写経やったことないけど。

むかしやってた映画のブログ( WordPress )のデータをこのブログに取り込もうとしたら、 mysqldump しといたデータが文字化けして読めなかった。 映画ブログのデータベースの文字コードは utf-8 にしてたけど、 Dreamhost の MySQL サーバーの defualt-character-set がおそらく latin1 になっていたと考えられ、 mysqldump するときに utf8 のデータが latin1 として export されてしまい文字化けを起こしていたっぽい。

vim で開いて e ++enc=utf8 してみたり、 nkr で変換しようと試みたり、ググって出てきた Perl のスクリプトで変換しようと試してみたけど直らなかった。この変換は MySQL 自身にやらせないとダメなのではと思い、以下を試したがダメ。

  • [x] latin1 で DB 作成し latin1 で import 、 utf8 で export
  • [x] latin1 で DB 作成し utf8 で import 、 utf8 で export

結局、 Stack Overflow にあった以下の方法で解決できた。

http://stackoverflow.com/a/18138899/1153050

一旦文字化けしたまま utf-8 の文字列として import し、以下の SQL を流す。

UPDATE [table_name] SET [column_name] = CONVERT(BINARY CONVERT([column_name] USING latin1) USING utf8);

やっぱり MySQL で化けたデータは MySQL で直すしかないみたいだった。

jikoku with BitBar

BitBar で私家版通勤タイマー (2) - portal shit! の続き。

時刻表を JSON 化した奴を食わせて 60 分以内(まえの記事では 30 分以内にしてるけど 60 分以内に変えた。パラメーターで調整できるようにすると良さそう)の次の電車一覧と発車時刻までの分数を表示できるようになった。あとはこれを BitBar で扱えるようにする。以下のようなシェルスクリプトを用意した。 BitBar をインストールして pupjq をインストールし、 go get github.com/morygonzalez/jikoku した上で以下のようなシェルスクリプトを ~/bitbar/jikoku.1m.sh という名前で保存すればよい。

#!/bin/sh
export PATH="$HOME/bin:/usr/local/bin:/usr/bin:/bin:$PATH"

echo ":train:"
echo "---"

go_filter=""
return_filter="筑 西 唐"
go_base="http://transit.yahoo.co.jp/station/time/28074/?gid=2480"
return_base="http://transit.yahoo.co.jp/station/time/28236/?gid=6400"

day=`date "+%a"`
hour=`date "+%H"`

if [ $hour -lt 13 ]; then
    go=true
else
    go=false
fi

case ${day} in
    "Sun")
        kind=4
    ;;
    "Sat")
        kind=2
    ;;
    *)
        kind=1
    ;;
esac

if [ $go = true ]; then
    url="${go_base}&kind=${kind}"
    path="/tmp/jikoku_go_${kind}"
    filter=$go_filter
    echo "Go | href=$url"
else
    url="${return_base}&kind=${kind}"
    path="/tmp/jikoku_return_${kind}"
    filter=$return_filter
    echo "Return | href=$url"
fi

if [ ! -f ${path} ] && [ ! -s ${path} ]; then
    curl -s ${url} -o ${path}
else
    current=`date +%s`
    last_modified=`stat -f "%m" ${path}`
    if [ $(($current - $last_modified)) -gt 3600 ]; then
        curl -s ${url} -o ${path}
    fi
fi

echo "---"

cat ${path} |\
    pup 'table.tblDiaDetail [id*="hh_"] json{}' |\
    jq '[.[] | { hour: .children[0].text, minutes: [.children[1].children[].children[].children[].children[].children | map(.text) | join(" ") ] }]' |\
    jikoku -f "${filter}"

echo "---"
echo "Refresh | refresh=true"

go_base には往路の、 return_base には復路の Yahoo! 乗換案内時刻表の URL が入る。 go_filterback_filter はユーザーごとに行き先を絞り込みたいだろうから(自分の場合は福岡市地下鉄の JR 筑肥線直通電車だけを絞り込みたかったので行き先表示に「筑」「西」「唐」が含まれるものだけがフィルタリングされるようにした。BitBar はファイル名を 1h.sh1m.sh とすることで 1 時間おきの実行や 1 分おきの実行など実行間隔を指定できる。

ちなみに当初は 5m.sh にしていたが、次の列車までの時間を表示するソフトが 5 分おきに実行とかだったらまずいことに気がついた。メニューバーで確認してまだ余裕だと思ってたら間に合わなかったみたいな事態になる。毎分処理が走らなければ意味がない。毎分実行しても問題ないよう( Yahoo! 乗換案内に迷惑をかけないよう)、時刻表を一時間キャッシュするようにした。もっと長期間キャッシュしても良いのだろうけど、 13 時を境に往路と復路を切り替えるようにしているので、まぁ 60 分もキャッシュすれば十分サーバーリソースにやさしいかなと思い、このような作りにしている。

最初は curlpupjq を組み合わせて簡単に作れないかな、と思ってやり始めて意外と簡単にできそうだと思っていたけど結局は結構複雑になってしまった。 Go で書いた jikoku コマンドの方も複雑かつ終電後の翌朝始発を考慮できていなくていまいち感がある。時刻表は平日と土曜、日曜祝日で異なるので安易に当日のデータを翌日のデータとして使い回せない(曜日判定しないといけない)。たとえば金曜日の終電後に翌朝の始発を金曜日の時刻表を使って表示してしまうとまずい。ちゃんと土曜日の時刻表を使わないといけない。しかし時刻表自体は curl で HTML を取得して pupjq で JSON に整形しているので、翌日の時刻表が必要になっても Go コマンドの方からはどうしようもない。

  • 時刻表の HTML を取得 (いまは curl でやってる)
  • HTML から必要な要素を取り出す (いまは pup でやってる)
  • 取り出した情報を使いやすい形式に直す (いまは pupjq でやってる)
  • 次の電車を表示する (いまは自作の jikoku コマンドでやってる)

という四つのステップを全部 Go でやった方がよいのかもしれない。そもそも jq 職人だったら jikoku コマンドみたいなものは不要で、次の電車を表示するところまで jq でできてしまうのかもしれない。

ちょっともやっとした感じは残ったけどなかなか便利ですのでよかったらご利用ください。

なお pupjq に依存してますんでインストールが必要です。

brew install pup
brew install jq

BitBar で私家版通勤タイマー (1) - portal shit! の続き。

JSON から情報を読み取って出力する奴は Ruby で書こうかなと思っていたんだけど、先日新しい上司と 1 on 1 をしていてどんな言語を使えるかの話になったときに Ruby と PHP とコールドフュ〜ジョン(と片手間 JavaScript )くらいしか使える言語がないということが判明してダメだと思ったので無理矢理 Go 言語で書いてみた。クソコードなので恥ずかしい。

package main

import (
    "encoding/json"
    "fmt"
    "os"
    "strconv"
    "strings"
    "time"
)

type Hour struct {
    Hour    string
    Minutes []string
}

func printLefts(m int, minutes []string, hour string) {
    for i := 0; i < len(minutes); i++ {
        mindes := strings.Split(minutes[i], " ")
        min := mindes[0]
        var Dest string
        if len(mindes) > 1 {
            Dest = mindes[1]
        }
        _m, _ := strconv.Atoi(min)
        left := _m - m
        if left > 0 && left < 30 {
            leftS := strconv.Itoa(left)
            takeM := fmt.Sprintf("%02d", _m)
            Str := leftS + " minutes left to " + hour + ":" + takeM
            if Dest != "" {
                Str = Str + " " + Dest
            }
            fmt.Println(Str)
        }
    }
}

func main() {
    decoder := json.NewDecoder(os.Stdin)
    timetable := make([]Hour, 0)
    decoder.Decode(&timetable)
    t := time.Now()
    h := t.Hour()
    m := t.Minute()
    var CurrentHour, NextHour Hour
    for i := 0; i < len(timetable); i++ {
        hour := timetable[i]
        _h, _ := strconv.Atoi(hour.Hour)
        if _h == h {
            CurrentHour = hour
            NextHour = timetable[i+1]
            break
        }
    }
    minutes := CurrentHour.Minutes
    printLefts(m, minutes, CurrentHour.Hour)
    if m > 44 {
        nextMinutes := NextHour.Minutes
        printLefts(m-60, nextMinutes, NextHour.Hour)
    }
}

こんな感じに表示される。

私家版通勤タイマー

あとはこれを BitBar で良い感じに読めるように出力内容を調整していけば良い。

Go 言語、 2 年くらい前に gyowitter っての作って Yo が来たら Twitter に晒すってのやってた以来に触った。変数のスコープとかがわかりづらかったし、 PHP っぽい雰囲気もある。やっぱり Ruby の方が書きやすいし好きだけど歯を食いしばって使ってみる。

以前は電車の本数多いところに住んでたので帰りの電車の時間とか気にしたことなかったけど、いまは郊外に住んでるので電車の本数少なくて、一本乗り遅れると駅で 20 分待たされたりする。特に遅くまで仕事してたりすると電車の本数がみるみる少なくなる。なので乗るべき電車に乗り遅れないように Yahoo! 乗換案内の通勤タイマーをよく使ってる。家まで帰る電車の発車時刻まであと何分かがカウントダウン表示されて便利。

ただ iPhone のウィジェットで見るとちょっともっさりしててだるい。 Pebble とかでサクッと確認できないかと思っているけど Pebble 入手して 10 ヶ月以上経つにもかかわらず Pebble 用のソフトを自分で作るという機運が高まらず今日に至る。

ある晩ふと、これって BitBar でできるんじゃねと思った。 BitBar は Mac のメニューバーに CLI で出力される情報を表示されることができるソフトで、 Netatmo Weather Station の計測値を表示するのに使っている。 Mac のメニューバーから二酸化炭素濃度や湿度確認できて便利。こんな感じ。これの通勤タイマー版が欲しい。

取り急ぎ時刻表の情報必要だけどちょっと探した感じでは簡単に時刻表取れるような API なかった。ので Yahoo! 乗換案内の時刻表をダウンロードして pup というコマンドラインの HTML パーサーで JSON 化し、それを jq に食わせて整形して良い感じの JSON にするという風にした。

# curl して HTML 取得
curl -s http://transit.yahoo.co.jp/station/time/28236/?gid=6400 | \
# HTML から必要な情報取り出して JSON 化
pup 'table.tblDiaDetail [id*="hh_"] json{}' | \
# JSON を良い感じに整形
jq '[.[] | { hour: .children[0].text, minutes: [.children[1].children[].children[].children[].children[].children | map(.text) | join(" ") ] }]'

得られる JSON はこんなのになる。(福岡市地下鉄空港線天神駅の姪浜方面の時刻一覧)

[
  {
    "hour": "5",
    "minutes": [
      "36",
      "42",
      "56 筑"
    ]
  },
  {
    "hour": "6",
    "minutes": [
      "8",
      "12 筑",
      "17",
      "26 筑",
      "34",
      "39",
      "43 筑",
      "56 筑"
    ]
  },
  ...,
  {
    "hour": "24",
    "minutes": [
      "6",
      "12 筑"
    ]
  }
]

これをコマンドラインで良い感じに表示するスクリプトを Ruby なり Shell Script なりで書いて BitBar に登録すればメニューバーから次の電車を確認できるようになり便利。

先日買った Weber コンパクトケトル の感想。

ワンタッチケトルと勘違いしてコンパクトグリルの方を購入してしまっていた。

簡単なバーベキューをする分には問題ないが、グリルの深さが浅いため空気の量が不足し、温度はあまり上がらないみたい。ステーキ肉を焼いてみた限りだと火力に不足はなかったが、コストコで売ってるような巨大な塊肉をローストするのには向かないっぽい。

Riverside Blog - Differences between the Weber 57cm Compact, Original & Premium BBQ's

見た目に関しても、リンゴのような丸みのワンタッチケトルの方がエレガントに見える。近所のバーベキュー屋や金持ちの家にあるのはそれで、買ったけど何かださいなぁ、思ってたのと違うなぁと感じてたけど、似た別の製品を買っていたということだった。

加えてなによりも大きいのが灰を掻き出すシステムの違いだ。こちらは排出フィンの取っ手が本体下部に付いているため、開け閉め時に耐熱手袋をつけなければならない(初めて使ったとき勝手がわからず手を火傷してしまった)。ワンタッチケトルの方は長さのあるレバーが付いていて素手でもフィンの切り替えができる。便利極まりなさそう。

さらにフィンの形状がコンパクトケトルに比べてより積極的に灰を掻き出すような構造になっており、ただ穴が開いたり閉じたりするだけのコンパクトケトルとは構造が異なる。穴が空いているだけだと底に溜まった灰を掻き出すことが難しい。掻き出し機構とセットになっているフィンは相当便利だと思う。

コンパクトグリルは名称にコンパクトと付いているが結構大きく保存場所はとるし、組み立ててしまった後では解体は難しくキャンプに持ち出せるようなメリットもない。値段もほとんど差がないのでどうせ買うならワンタッチケトルの方がよいと思う。自分はヨドバシでワンタッチケトルより少し安く売られているためコンパクトケトルを買ってしまったけど、 Amazon だったらワンタッチケトルでも同じくらいの値段で買える。

アウトライン・プロセッシング入門を読んだ

『アウトライン・プロセッシング入門』という本を読んでみたら意外とよかったのでアウトラインとアウトライナーについて思っていることを書きます。

読んだきっかけ

WorkFlowy というアウトライナーについて調べてたらよく紹介されていたので読んでみた。 WorkFlowy というのはウェブベースのアウトライナー。 Google で「 WorkFlowy 」で検索すると Evernote でライフハックしまくりお父さんみたいな人たちが群生してる様子が観察できる。犬のえさやりタスクや子どもを公園で遊ばせる予定などをどうやってクラウドで管理するかみたいなことをアツく語っている。

良かったところ

アウトライナーの使い方を見直した。最近の自分のアウトライナーの使い方は間違っていた。

アウトライナーとは

文章の概要・目次を書くために使うものというのが一般的な理解。文章を箇条書きにして書くことができる。箇条書きにした内容を入れ子にしたり、順番を並べ替えたりできる。しかし概要や目次の作成だけにアウトライナーを使うのはもったいない、というのが本書の趣旨。

自分のアウトライナーの使い方

以前はよくアウトライナーを利用していたが、最近はあまり使わなくなってしまった。暇だったためブログの記事を書くのに時間を割くことができたので、アウトライナーで入念に内容を練ってから書くようなことをしていた。ブログに投稿する直前までアウトライナーで書いていたので、書きながらつながりのおかしいところがあると文章を入れ替えたり見出しを付け替えたりが楽だった。

最近

職業プログラマーになって Vim を使うようになり、 Vim で書くのが一番速く書けるようになった。何でも Vim で書くようになり、アウトライナーは最初のアウトラインを考えるときだけ使うようになった。このようなスタイルではアウトラインが最初に固定されてしまい、つながりが不自然なところがあってもそのまま突き進むしかなく、文章を書いていて何とも言い表しようのない息苦しさがあった。1

アウトラインはどんどん変わっていくべき

アウトラインは決して不変なものではなく、文章を書いていてアウトラインが修正されていくのはよいことだといえる。アウトラインを修正しながら本文を書いて行くことができるのがアウトライナーのメリット。雑に書き出された断片的な内容を「シェイク」という過程で並び替え、論旨を整えていくプロセスが良い文章を書く上で重要。最初のアウトラインの作成にだけアウトライナーを使うのはアウトライナーのメリットを享受できずもったいない。アウトラインを先に作ってからの文章作成はウォータフォール型の開発に似ていると思う。アウトライナーで最初から最後まで書くのはアジャイル型の開発に似ている。小さく区切って作業を進め、こまめに振り返り、変化に対応することで良い成果物=読みやすい文章ができあがる。

アウトライナーで最初から最後まで書くことの問題点

アウトライナーで書けば万事オッケーかと言われるとそうとも限らない。書き終わった文書の管理が問題となる。

いま

memolist.vim で書いて Day One.app に保存している。 Terminal で grep するか Day One の検索窓で検索すると必ず目的のものにたどり着ける。

アウトライナーで文書作成

個々のファイルに内容が分断してしまう。こうなると検索しづらく、参照性が低い(「ファイルの壁」問題)。ただ一部のアウトライナーはこの問題に対応している(後述)。

アウトライナーで書いて Vim で Markdown 形式に整えて清書、 Day One に保存すれば検索できそうだが若干面倒くさい。しばらく頑張ってみる。

Mac で使えるアウトライナーいろいろ

Tree 2

http://www.topoftree.jp/tree/

個人的に一番よく使ってる。安くて機能シンプル。 iOS 版がないのがちょっと残念。

OmniOutliner

https://www.omnigroup.com/omnioutliner

昔は OS にバンドルされてて、 .plist の拡張子のファイルを開こうとして勝手に立ち上がったりしてうざかった。最近の OmniOutliner は横にカラムを追加して Excel みたいな使い方できる。一見、地獄っぽい。Excel 方眼おじさんに OmniOutliner を与えると泣いて喜ぶかもしれない。

TaskPaper

https://www.taskpaper.com/

実は TaskPaper はアウトライナーそのもの。タスクを書き出すという行為、アウトラインで考えを整理する行為に似てる。したがってよいタスク管理ソフトはアウトライナー的な側面を持つ。実際アウトライナーでタスク管理する人は多い。

MindNode

http://mindnode.com/

実はマインドマップも OPML (アウトラインプロセッサーの共通フォーマット)で書き出せるためアウトライナーとして使える。ミーティングなど大人数でブレインストーミングしながらアウトラインを作成するときは MindNode のようなマインドマップの方がよい。

WorkFlowy

https://workflowy.com/

WorkFlowy なら先述の「ファイルの壁」問題を解決してくれる。従来なら個々のファイルに分かれていたアウトラインを一つに統合し、個々の Node として扱う。ファイルは一つしかないので分断が起こらない。一つのアウトラインの中に自分のすべての思っていること・考えていることが保存される。

WorkFlowy は「ファイルの壁」を突破した使い方が出来るが、 SaaS なのでオンラインでないと使えない。飛行機の中などインターネットにつながらない場所でアウトライン書けない。完全ローカルで使える買い切り型の WorkFlowy があったら最高2。オフラインでも使えるインストール型のアプリの方が動作が速くて快適なのは自明だ。アウトラインが増えてくると結構高い Pro プランにしないといけないのもつらい(月額 $4.99)。

まとめ

自分の文章の書き方、アウトライナーの使い方を見直した。文章作成の大半の部分をアウトライナーで行い、 Vim を使うのは文章の最終仕上げ段階だけにとどめたい。そうすることでつながりのおかしい文章や読みにくい文章を避けることができる。

『アウトライン・プロセッシング入門』は Kindle オーナーライブラリにあって無料で読めるので Amazon プライム会員の人は読んでみるといいかも。よい内容は最初の方に集約されています。

おまけ

このブログの記事でアウトライナーで割と最後まで書いてた文章の例。

  • 家を買ったので得られた知見を共有します
    • 最初は普通に書いていたが文章が冗長で読みにくさを感じたので文章のダイエット目的で箇条書きにしてアウトライナーで書き直した。
    • はてブで 2000 ブックマークくらい付いた。
    • 箇条書きのつながりが良く読みやすかったのかもしれない。
  • 糖質制限で脱デブ成功しました
    • ほとんど最後までアウトライナーで書いたが「シェイク」不足。
    • 文章が読みにくく、ほとんどブックマークされなかった。

  1. 天性の Vimmer は「シェイク」(後述)も Vim で出来るかもしれない。 

  2. Google Chrome 限定だけどオフラインで使える Chrome アプリもあるっぽい。WorkFlowy - Chrome ウェブストア