gyunyuというRTMアプリを作りました

Jan 06, 2012

これは何か

wtnabe/gyunyu - GitHub

Ruby で書かれた
コマンドライン向け RTM アプリ

です。

出ました、またコマンドラインツールです。

gyunyu という名前は、

なんか日本語名の方がRubyっぽい

というのと、RTMなんとか、RTなんとか、でどう考えてもかっこいいのが浮かばなかったからです。

使い方

$ gem install gyunyu
$ gyunyu
(ヘルプ)
$ gyunyu -c today_yet -l 仕事 -d name,estimate
(今日まだ終わっていない仕事を見積もり時間とともに出力)

こんな感じです。

できること

登録済みのタスクを検索して出力します
出力フォーマットは CSV, YAML, JSON です（デフォルトは CSV）
「期日」だけですが、日本時間でも正確に今日とか昨日とかを検索できるフィルタを用意しました。面倒な検索条件を自分で書く必要がありません。

今のところ ( 0.2.0 現在 )

CRuby 1.9.2 でしかテストしてません
いろいろ考えたんですが、まだ export コマンドしか作ってません

なんでこんなもの作ったか

個人的に以前から作業時間の記録などをもとに作業効率の自己評価とかやってるわけです。えぇまぁ積極的にやりたいわけじゃないですけど。で、そのためにすでに入力済みの RTM の情報が記録としても使えるじゃーんと思って完了済みタスクを開いてみてたんですが、

結局手作業で転記するしかない

というおよそプログラムの書ける人間としてはやってはいけない単純作業をくり返していたんです。半年くらい。でもまぁそれまではおおよそ分かればいいしと思っていたのと、転記の際に RTM には書き漏れていた情報を追記したりして回していたのです。

が、いよいよ時間の記録の方を重視することになったので、あーこれはやっとれんということで RTM API Key を取得してちょっとずつ動かしてみていたのでした。

苦労したところ

モダンな認証方法がよく分かってなかった
RTMの「見積もり時間」が「入力したまま」の状態で入っていて、数字としての意味を解釈するのに一手間必要だった。
- ということで wtnabe/rtm-time - GitHub もよろしくね！
API で返ってくるタスクは task を包む taskseries という謎の構造を持っていた
RTM API では日時の表記に UTC の ISO8601 フォーマットを要求するんだけど、どうも指定した期間の情報がちゃんと取れないと思ったら フォーマットとしては UTC の ISO8601 を要求するけど、実際の時間について timezone の変換は不要 という変な仕様になっているようだった。
- たぶんアカウント情報の timezone の設定をいい具合に使ってくれてる。
- ただし返ってくるデータは正しく UTC の timezone になってくるので変換が必要

Special Thanks to

@mootoh and mootoh/rtmilk - GitHub !

今後は

rails console みたいな gyunyu console が作れたら task の作成や更新も楽にできそうだなと思うんだけど、今のところそんなもんできそうな気がしないです。

余談

これを作った時点での RTM の時間関係の filter の動作をメモしておきます。

due:today は JST だと today か yesterday のタスクが取れる
- 単に9時間ずれたタスクのリストが取れるのではない
- search 発行時点での UTC の today の日付を localtime に当てはめて 00:00:00 から 23:59:59 までのタスクが取れる
- たまたま夜に実行すると今日の分が取得できる
dueAfter に正確な時刻を入れる場合は1秒前を基準にする。 >= ではなく > 相当。たぶん due 以外でも一緒。

自分の環境を手っ取り早く再現するツールの構想

Jan 06, 2009

※ 実際にはこの日記は3月に書いていて、すでにツールはある程度形になっています。

wtnabe's myenv-builder at master - GitHub

とりあえず dot file にリンクを張る

年末からいい加減 .zshrc とか .emacs とか整理しなきゃと思って作業しているわけだけど、これはただ整理するだけでなく、

一本化したうえでバージョン管理することで、どの環境でも間違いなく最新のものを利用できるようにする

ことを目的にしている。しかしドットファイルはホームディレクトリに置くのでそのまま素直にやると

~/
|-- .colordiffrc
|-- .fd2rc
|-- .irbrc
|-- .screenrc
|-- .subversion/
|-- .zshrc
|
|   ものすごく大量の要らないファイル
|
`-- ...

という形になって、ものすごく無駄かつ現実的じゃない。そこでこういう形を取ることにした。

~/
|-- .colordiffrc -> ~/dotfiles/colordiffrc
|-- .fd2rc -> ~/dotfiles/fd2rc
|-- .irbrc -> ~/dotfiles/irbrc
|-- .screenrc -> ~/dotfiles/screenrc
|-- .subversion -> ~/dotfiles/subversion/
|   `-- config
|-- .zshrc -> ~/dotfiles/zshrc
`-- dotfiles/
    |-- .svn/
    |-- colordiffrc
    |-- fd2rc
    |-- irbrc
    |-- screenrc
    |-- subversion
    |   `-- config
    `-- zshrc

dotfiles/ というディレクトリを掘ってここにドットファイルの実体を置き、このディレクトリをバージョン管理する。使うときにはホームディレクトリからこのディレクトリの中の対応するファイルに symbolic link を張る。

実際にはこれは rake の練習を兼ねているので dotfiles/ の中に Rakefile を置いて、自動で link を張れるようにしている。ホームディレクトリに対応するファイルがあったら当然止まっちゃうんだけど、そこはメッセージを分かりやすくしたうえで止まるままとしておいた。問答無用で消しちゃったりすると悲しいことになるかもしれない。

Windows でどうするかは未定

問題は Windows で。

Windows には symbolic link の機能はない。でも Windows でも同じように恩恵に預かりたい。まぁ Windows を使う時間は長くないのでそんなに困らないんだけど、長くないからこそ使うときにはすぐにいつもの環境になってほしい。環境構築に時間を掛けるのが楽しい時期はとっくに過ぎてしまったもの。

なんか方法ないかなーと思いながら

Rubyist Magazine - Ruby Library Report 【第 4 回】 Win32Utils

を読みつつあれこれ試してみたけど、やっぱ無理っぽい。shortcut を作っても認識はされないし、hard link でいいかと思ったけど hard link はディレクトリに対しては無理だ。

どうしたもんかなぁ。

getmail + maildrop は確かに便利そう

Jan 06, 2007

この間の続き。以下はドキュメントを読んだ時点での感想。（まだ動かしてない）

getmail は MDA 要らずで pop3/imap4, mbox/Maildir 対応

取得プロトコルは置いとくとして。

まぁ通常の Unix 系のホストならローカルメール配送用のプログラムが何かしら動いているのでこれはたいしたメリットにはならないんだけど、特定用途に特化しているとか、わけあって cygwin 上で動かしますとか、そういう場合に便利そう。独自に filter の呼び出しができるので振り分けとか意外と細かいことができると思う。

ただし転送したい場合はたぶん MDA が必要なので、あれもこれもやりたいという場合には最初から MDA と組み合わせてそっちで行うべきなんだろう。

Python が立ち上がるのはどうかとも思ったが、逆に Python が動けばよいのでプラットフォームの自由度は上がっている気がする。細かい処理はあとで考えるとしてとりあえずメールを取ってくるだけに集中するならこれさえあれば済む、というのはなかなか魅力かも。

maildrop は記述が Perl っぽい

お次は MDA の maildrop. さかんに一時ファイルを作ってメモリを節約してますよ、と謳っている。

好き嫌いは分かれると思うが、procmail の書き方よりはまだ Perl っぽい方が楽な気がする。PCRE を使っているので条件を記述する際に悩まなくていいのが嬉しい。（謎のオレ正規表現とか実装されちゃうと仕様がよく分からなくてつらいって意味。）

フィルタとしては Lens も捨てがたい

それは Ruby で書かれているので簡単に POP before SMTP 対応や submission 対応にできるから。これ、何が大切かと言うと、forward の自由度が上がるってこと。

いやね、監視したいサーバが内部向けのサーバで、自分たちの自由にできる環境に固定 IP で逆引きもできる SMTP サーバが立てられない場合とかあるでしょ？¹ そういう場合、システムからのアラートメールを自分（携帯とか）宛に転送しようと思っても最近は outbound port25 block で submission 使ってね、なわけですよ。さてどうする？と。こんなとき、Lens の smtp の部分をちょこっと書き換えれば ok っていうのはかなり便利だと思うんだな。

ところで今週末は時間が取れないから作業はしばらく先になっちゃうんだなぁ。残念。

SMTPクライアント

[2007-02-08 追記]

Lens 改造にこだわらなくても LightWeightSmtpClients - mutt-j wiki などの情報をもとに SMTP クライアントを利用すればよさげ。見た感じ msmtp が

システムワイドの設定とユーザー独自の設定の二段構えにできる
ファイルにも syslog にもログを吐ける

など、取り回しよさげな雰囲気。

以前は SMTP サーバが relay の際に SMTP-Auth で認証を受ける SMTP クライアントになってくれれば、内部に relay 用のサーバを一つ立てるだけで済むのにと思っていたんだけど²、考えたら「その際、認証に利用するアカウントは誰のものを使うんだ？」という問題もあるのよね。まぁシステム丸ごと管理してるから外部に投げたいんじゃいということであれば、組織の管理用アカウントを使えばいいのかなとも思うところだけれども³。

ユーザー独自の設定つっても root 権限持ってる人はその気になればパスワード覗き見できるので、それもどうだという感じはあるかもしれないけど、その辺は個人アカウントと管理者アカウントを分けるとか運用でカバーしろということでいいかな。用途が用途だけに生パスワードを書かなきゃならないかどうかなんてあんまり気にならないな。

cf.