| @技術/プログラミング

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 コンパクトケトル の感想。

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

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

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

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

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

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

| @Mac/iPhone

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

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

読んだきっかけ

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

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

OmniOutliner

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

TaskPaper

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

MindNode

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

WorkFlowy

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

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

なお以下のリンクから登録してもらえると僕とあなたの無料で使える WorkFlowy のアウトライン数上限が 250 個増えるので登録してやってもよいという方は是非よろしくお願いします 🙇🏻

まとめ

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

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

おまけ

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

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

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

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

| @散財

森井ゴンザレスさん(@morygonza1ez)が投稿した写真 -

家から近い海沿いの金持ちの家やバーベキュー屋に置いてある黒色で円形のバーベキューグリルが突如として欲しくなってしまい、勢いで買ってしまった。コストコで激安販売されているというネット上の情報を目撃して行ってみたけど今は売っていないみたいで買えず、コストコの店内からヨドバシのオンラインショップで購入。翌日届いた。あいにくの雨でまだ火入れできていない。一緒にスターター(チムニーというやたら可愛い商品名)も買った。なんか火起こしが劇的に楽になるやつらしい。コストコで豆炭も大量購入しておいたのでバーベキューやるのが楽しみ。ただグリルを買うので散財してしまったのでバーベキューやるにしてもしばらくは肉なしかな…。

| @散財

コストコ初めて行った。年会費は税込み4752円だった。高い。Weber のバーベキューグリルが格安で買えるという情報をネットで目にしていたのでそれ目当てで行ってみたけど売ってなかった。

うちからコストコに行くためには高速に乗らないといけない(乗らなくても行けるけど時間が二倍くらいかかるし運転疲れる)。すると毎回往復するだけで交通費がガソリン代合わせて2000円ほどかかる。多少安く食材が買えたとしても交通費を加味するとあまりコストパフォーマンスよくない。コストコでしか買えない○×が欲しいとか、IKEAのついで(同じ方角にある)に、という理由で行く分には良さそう。

コストコ、グラムあたりの価格は安いのかもしれないけど、売られている単位が巨大で高い。牛肉とかめちゃ安く買えるのかと期待して行ったけど意外と800円/100gとかするし、しかもそれが1kg単位でパック詰めされてたりするので8000円くらいして一般人には手が出せない。というかグラム800円もしたらアメリカ産じゃなくて国産の和牛が買える。高いわ。

チーズやソーセージも良いものあったけど塊が巨大で高い。とにかく安く買い物したい、というような人には向かない場所だと思った。

そもそも売り方の発想が日本向けじゃなくて、あんなに巨大なパックで食材を買うのは住宅事情的に無理。日本の小売業者は消費しやすいパッケージで消費者の需要に合わせて小口で販売してくれててありがたいなぁ、さすが日本人ならではの細やかな心配りだなぁと思えて感心した。戦争になったらコストコのような余ったり無駄がでても良いからがんがん作って戦地に届けるというやり方の方が効率よく物資が行き渡りそう。日本の小売業者のように小分けにして小さく割り振るみたいなやり方は戦地での物資不足を招きそう。やはり第二次大戦は負けるべくして負けたんだなぁと思った。

なおコストコはアメリカンエキスプレスかUCカードのコストコバージョンみたいなやつしかクレジットカード決済に使えない。なので会員登録するときにアメックスへの入会を勧められたけど年会費高いし分不相応だと思うので断った。しかしレジに並んでいるときに少し後悔した。コストコはまとめ売りしているので商品の単価が高く、大して買い物してなくてもすぐ3万円くらいになってしまう。これを現金で支払うのは自分のキャッシュフロー的には厳しい。アメックスを持てる人か現金払いも余裕でこなせるリッチマンしかコストコは楽しめない。お金持ってる人がアメリカの物量に脳みそやられて金を垂れ流す場所という感想を持った。

せめて家の近くにあるなら小洒落たオードブルやサラダ、割とうまいパンなんかを時々買いに行ったりできて便利だろうけど、離れたところに住んでいる人が高い金払って会員になり交通費かけて買い物に行くのはもったいないなと感じた。

| @技術/プログラミング

京都国際会館

京都であった RubyKaigi 2016 を観覧してきた。 RubyKaigi 、つくばであった 2010 がこれまでの人生での唯一の RubyKaigi で、人生二度目の観覧だった。

RubyKaigi 2010 の思い出

一度目のときは少し前に増田に上がってた勉強会ゴロ状態(受付の人と技術書を買ったジュンク堂の人と以外誰とも会話をせずに帰宅)だった。

ちなみにこのとき ESM の企業発表を見に行って、 ESM に転職したばかりの hsbt さんの姿を初めて目にした。なんか入社したばかりなのに社内ブログで暴れてて愉快、みたいな紹介のされ方だった。その後同じ会社で働くことになるとは思いもしなかった。

ESM の発表はとにかく鮮烈に印象に残ってて、ペアプロのライブコーディングだった。 ursm さんが CRM か何かの開発を実演してた。まず最初に落ちるテストコードを書いて、その後にパスするプロダクトコードを書く、というやつを初めて目にして、田舎で HTML コーダーをしつつちょっとしたプログラムを書いてた自分は衝撃を受けた。黒い画面の Vim で高速にコードを書いていく様がとにかくかっこよかった。はやくこういう感じでコード書けるようになりたい、と思ったものだった。

クックパッドの企業発表みたいのも聞きにいって、このときクックパッドもまだそんなにエンジニアの数多くなかったはずで、同じくはてなから転職してきたばかりのセコンさんが話してるのを聞いてトートバッグもらって帰った。

YAPC::Asia Tokyo 2015 の思い出

去年の夏、 YAPC で東京に行って、このときはペ社時代の知ってる人としゃべったりして無言の帰宅は避けられた。

YAPC 2015 は気がついたときには懇親会の申し込み締め切られててどこにも行けず、一人浜松町の宿泊先の近くの「とにかく安くて量が多い」と食べログにレビューが書いてある寿司屋に入って一人で寿司を食べたら寿司がねちゃっとしてて具合が悪くなったりしてた。

RubyKaigi 2016

今年も発表する側にまわったわけではないので一般ピープルである点は同じだったが、これまで話したことなかった人と話せたのがよかった。

取り分けよかったのが Fjord 社の komagata さんと話せたことだった。今後の Lokka の方針をどうするか開発者会議的なものを開催してババっと方針を決めましょう、という話をした。 Lokka 、思い入れがあるので積極的にメンテナンスに関わって今後も長く使い続けていきたい。

一日目

一日目は Kaizen Chat についてのブログ記事を公開するというタスクがあって、 Matz のキーノートとかはあまりじっくり聞けなかった。記事公開後に会社のブースで自分のシールを配布したりして公私混同してた。

今年の RubyKaigi は懇親会の枠が大きかったおかげで申し込みそびれるということにならなくてよかった。

オフィシャル懇親会で Fusic 社の k1low さんと初めてゆっくり話をした。Fukuoka.rb で顔を合わせることあっても一緒に酒飲んだりする機会なかったので RubyKaigi に来て初めてじっくり話すという感じだった。

ヒトデさんとその愉快な仲間たちの皆さんとも話して、 shikakun はオリジン弁当ばかり食べてるくせにやたら調理器具を持っていて不可解だとか、風呂蓋付きの浴室がある部屋にすんでいていけすかないという話をした。

Twitter で 8 年くらい前にハゲクラスタとしてわいわいやってた send_ さんとも再会できて、お互い帽子をかぶった状態でいまの仕事の話をしたりした。

オフィシャル懇親会のあとは、ヒトデさんオーガナイズの二次会に参加させてもらった。デンエンという物価が崩壊してる飲み屋に行ってタワーから注いで飲むビール飲みまくった。クックパッド社の著名エンジニアの皆さんと対面に座ったけど人に自慢できるような OSS とかなくて雑魚いので自己紹介に困ったが、とりあえずこういうアイコンのものですと言ってシールを見せたら「あ、なんか見たことある」という感じになったのでシール便利だった。

二日目

朝一番の Justin Searls さんのリファクタリングについての発表がとにかく面白かった。

去年 YAPC で GitHub の人が話してた sicientist と似てるけど、リファクタリング前後のコードで A/B テストをする gem の紹介。新しい方のメソッドが例外投げたら rescue して古い方のメソッドを実行するというのが面白かった。本番にも安心して投入できるとのこと。

三日目

午前二番目に tkawa さんの HTTP クライアントについての発表聞いた。 HTTP クライアント乱立しててひどい、 API をラップしてリモートサーバー側のクラスを再現するような異常なクライアント多くて、 REST API とは一体何なのか状態だ、みたいな話だった。言われてみれば確かにそうかもしれない。独自の API クライアント作ることなく、 Rack が Rack Middleware を use して拡張していくみたいに、 HTTP クライアントの側でも Middleware を use していくのがよい、そこで Faraday ですよ、という話で、あ、 Faraday ってそういうことを目的にしてたんだと膝を打った。

午前中最後の Chris Arcand 氏の発表が面白かった。

Ruby のコードを解析して呼ばれてないメソッドを調べる、という発表だった。実際に Rails プロジェクトとかで使うのは大変そうに見えたけどいまから君のプロジェクトに投入できるよ、 Rails もダイジョブみたいなことを言ってた気がするのでスライド見直したい。

最後のセッションの前、一日目のデンエン会で知古を得た pastak さん見かけたので uiureo さんを紹介してもらって話をした。 uiureo さん、初対面だけど話しやすくて好青年な感じだった。 r7kamura さんとも少ししゃべらせてもらってよかった。

飛行機の時間の都合があったのでクロージングまでは残らず、最後のキーノートの途中で離席して帰途についた。ホールを出ようとしたところで滑り込みで会場にやってきた元同僚の hisaichi551 さんと邂逅して自分のシールを何枚か雑に渡した。ゆっくり話がしたかった。

京都での開催について

京都での開催良かった。個人的には福岡からだと東京に行くよりも京都の方が近いので移動が楽で良い。首都圏からの大多数の参加者も京都に宿泊して参加するので夜通しどこかで RubyKaigi 関連の飲み会が開かれてる感じで祝祭感あった。夕方から観光したりできて海外からの参加者も満足度高いのではないかと思う。京都国際会館のインフラも素晴らしかった(施設、庭園、食事内容)。スポンサーの提供で振る舞われたお弁当おいしかった。

総合的な感想

RubyKaigi 、海外からのスピーカーの発表はどうやってよいコードを書くかとかリファクタリングとかの話が多い。日本人の発表者の人は Ruby を開発する方の話が多い。( Ruby コミッターのほとんどが日本人だから)。なので Ruby 本体の開発に興味ない人( Ruby 開発者ではなく Ruby ユーザーなプログラマー)はぽかんとすることが多いかもしれない。自分は結構ぽかんとしてた。

あと今回多いと感じたのが Concurrency についての話だった。どうやって Ruby で並行性を上げるかという話。 Thread は難しいので素人は手を出すな、ということはわかったけど Ruby 3 の Guild というので素人でも Concurrent なプログラムが書けるようになるかどうかは今ひとつわからなかったので資料を読み直したい( reuibld.fm の Episode 158 を聞くと良い復習になりそう)。 Ruby 3 に並行処理の使い勝手が向上する前に、他の言語で並行処理について学んで準備をしといた方が良さそうだと感じた。

2010年の勉強会ゴロ状態のときに比べれば、何人かの人と話したりシールを配ったりすることができて、有意義な時間を過ごすことができたと思う。ただアイコンの気持ち悪さで認知されるよりも書いたソフトウェアの知名度で認知される方がよいので、カンファレンスに行って自己紹介するときに「○×というソフトを作ってます」と言えるようになりたい。仕事だけじゃなく、オープンソース活動もやっていけるように頑張りたいな、と気持ちをあらたにした会でした。