Subscribed unsubscribe Subscribe Subscribe

詩と創作・思索のひろば

ドキドキギュンギュンダイアリーです!!

Mackerel + peco + zsh でコマンドラインにホスト名を補完する

複数のサーバが関わっている環境では、ホストに人間が分かる名前を関連付けなければ運用がスケールしなくなるものです。その名前はホスト名だったり、ロールやタグのようなものだったりすると思いますが、仮にホスト名を利用するなら、DNS を用いて名前とホスト(の IP アドレス)の対応をつけるようなこともできるでしょう。DNS が利用できない場合は、/etc/hosts に書くというようなのもありですね。

しかしホスト名を直接利用した運用というのは意外と難儀なところがあって、とくに自分のように普段サーバを扱った作業をあまりしないアプリケーションエンジニアなどは、「前に接続したことあるあのホストは何だっけ……」といううろ覚え状態に弱い。名前の一部は覚えているわけなので、シェルの履歴を検索すればなんとかなるのですが、一度も接続したことがなければ目当てのホストを探し出すことはできません(この、接続したことがあるかどうかに確信が持てないのもストレス)。

Mackerel と mkr

さて、Mackerel ははてなが提供するサーバ管理・監視サービスで、私もふだん利用しているものなので、これを使うことを考えます。Mackerel ではサーバはホスト名だけでなくサービス/ロールにひも付きますから、たとえホスト名に意味のある名前をつけない運用であっても、サービスとロール("app" や "db" など)をたどることで目当てのサーバを見つけることができます。この側面を利用すると、とても人間にやさしい。ここで mkr というツールを用いて、関心のあるホストを簡単に見つけられるようにする方法を実現します。

mkr は Mackerel が提供する API の公式クライアントです。Go で実装されていて、go get またはバイナリのダウンロードで利用できます。

go get github.com/mackerelio/mkr

mkr では、

  • Mackerel へのホストの登録(mkr create
  • ホスト情報の更新(mkr update
  • メトリックの投稿(mkr throw
  • ホスト情報の一覧(mkr hosts

などの API がコマンドラインインターフェースで利用できます。基本的には MACKEREL_APIKEY 環境変数に Mackerel の API キーを設定して使いますが、標準的な構成で mackerel-agent を稼働させているホストで実行する場合にはその設定ファイルから API キーやホスト ID を再構成してくれるため、便利なことに追加の設定なしですぐ使えるようです(詳しくは README をご覧ください)。

ここではホスト情報の一覧(mkr hosts)を使うことになりますが、このコマンドには -f オプションが定義されていて、Go の text/template 形式で出力を加工できるようになっているので、これを利用します。

mkr + peco + zsh による実現

f:id:motemen:20150630233012g:plain

上のスクリーンキャストでは Mackerel に登録しているサーバをそのホスト名およびサービス/ロールとともに一覧し、peco であいまい検索を行って、選択したものをコマンドラインに補完する、ということをしています(というのを ^[o にマッピングしている)。コマンドラインには直接 IP アドレスを展開し、末尾にコメントとしてホスト名を記録しているので、シェルの履歴にもコンテキストが残りますね。

これは以下の zsh 関数とシェルスクリプトの組み合わせで実現しています。

complete-mackerel-host-ip

zsh 関数 complete-mackerel-host-ip がキモで、入力中の単語から Mackerel に登録しているホストのあいまい検索を行ない、入力中のバッファに展開します。環境変数を用いず第1引数に API キーを取るようにしているので、環境変数以外の場所でキーを管理しているような場合にもたぶん簡単に使えるはずです。ちなみにあまり用途はないかもしれませんが第2引数には API キーの名前を指定できて、 複数の Mackerel オーガニゼーションを並行して利用している場合にはこれでキャッシュを分離できるようになっています。

ここでは IP アドレス部分のマッチをおこなわないよう指定できる fzf を利用していますが、filter 変数を 'peco' に書き換えることで peco にもすぐ切り替えることができます。

https://gist.github.com/motemen/2b0656be9e2acf32b35d#file-complete-mackerel-host-ip-zsh

mkr-hosts-tsv

これはキャッシュしつつ Mackerel のホストを TSV で一覧するだけのシェルスクリプト。PATH の通るところに置いてください。ここで mkr hosts とその -f オプションを利用していいます。

https://gist.github.com/motemen/2b0656be9e2acf32b35d#file-mkr-hosts-tsv

参考資料

Go Conference 2015 Summer で Go の REPL gore の話をしてきました & gore 0.2.1

Go

去年からこちら Go の話をしたり聞いたりする機会があればぜひ言ってみたいと思っていたのですが、このたび Go Conferecne 2015 Summer の話を聞きつけて、うまいことスピーカー枠に入ることができたので、前に作った Go の REPL(正確には違うんだけど)である motemen/gore の話をしてきました。

speakerdeck.com

gore の紹介は過去のエントリ コード補完もできる Go の REPL「gore」を作った - 詩と創作・思索のひろば にある通りです。今回はその実装に若干立ち入った紹介をしました。

この日のトークは oracle の紹介にはじまり Go の静的解析めいた発表が多く、個人的にはとてもわくわくさせられた内容でした。時間の都合もあって、gore(と go-quickfix)の面白い部分の詳細の話はぜんぜんできなかったので、また別の機会にできればなと思います。しかし今回は思いがけず Gopher 君人形をもらえて本当にうれしかった! 運営のみなさま、楽しいイベントをありがとうございます。

gore 0.2.1

また GoCon 後のテンションで、gore のバージョンをアップデートしました。主な変更は以下のとおりです。

  • -pkg=<path> フラグを追加しました。あたかも特定のパッケージの中にいるかのようにして、gore セッションを開始することができます。
% gore -pkg=github.com/motemen/gore
gore version 0.2.1  :help for help
added file /Users/motemen/dev/go/src/github.com/motemen/gore/commands.go
added file /Users/motemen/dev/go/src/github.com/motemen/gore/complete.go
added file /Users/motemen/dev/go/src/github.com/motemen/gore/liner.go
added file /Users/motemen/dev/go/src/github.com/motemen/gore/log.go
added file /Users/motemen/dev/go/src/github.com/motemen/gore/main.go
added file /Users/motemen/dev/go/src/github.com/motemen/gore/node.go
added file /Users/motemen/dev/go/src/github.com/motemen/gore/quickfix.go
added file /Users/motemen/dev/go/src/github.com/motemen/gore/terminal_unix.go
added file /Users/motemen/dev/go/src/github.com/motemen/gore/utils.go
gore> version
"0.2.1"

ここでは version 定数 が評価されています。

ちなみに -pkg の指定にはパッケージのパスのほか、ディレクトリを指定することもできます。

  • 内部で motemen/go-quickfix を使うようにしました。これは GoCon の仕込み的な変更です。何か変なことがあった場合には GitHub Issues 経由でお知らせください。
  • ある形の式を評価するとエラーが発生していた件を修正しました。(#21

アップデートは以下のようにして行えます。(開発者向けのツールなのでバイナリの配布はしていません)

% go get -u github.com/motemen/gore

Google Apps Script の TypeScript 型定義ファイルを作った

Google Apps Script は JavaScript っぽい言語で Google 製品の自動化を行える便利環境で、定期実行や外部との HTTP 通信など、意外と痒いところに手が届く出来であり、今となっては身につけておくとよいツールのひとつと言えるでしょう。GAS の開発はおもにオンラインエディタでおこなうこととなっていて、ここで便利なのは補完が効くこと。慣れたエディタで書くこともできるけれど、補完のない環境で、多岐にわたる API をリファレンス引きながら書くというのは心細い。

そもそも JS を書くなら静的型の恩恵のある TypeScript で書きたいという人類原初からの欲求もある。TypeScript は非 TS なライブラリや環境むけに型付きの API 宣言ファイルを用意することで、静的型チェックや補完に利用できる仕組みがある(.d.ts という名前でこれらを用意する)。それならば、GAS の API の型定義ファイルを用意してしまえば、好きなエディタで GAS の補完をしながら書けるはずだと考えるのは、当然の帰結でしょう。

というわけで作ったのがこちら。

motemen/dts-google-apps-script · GitHub

使い方

入手と利用

Spreadsheet や Drive など製品ごと(正確にはリファレンスのカテゴリごと)に定義ファイルを分けているので、必要な物を参照するようにしてください。

けっこうな数のファイルがありますが、主だったところは以下でしょう。定義されるグローバル変数を併記してあります。

  • google-apps-script.base.d.ts -- Logger とか
  • google-apps-script.calendar.d.ts -- CalendarApp
  • google-apps-script.document.d.ts -- DocumentApp
  • google-apps-script.drive.d.ts -- DriveApp
  • google-apps-script.gmail.d.ts -- GmailApp
  • google-apps-script.spreadsheet.d.ts -- SpreadseetApp
  • google-apps-script.url-fetch.d.ts -- UrlFetch

とりあえず DefinitelyTyped には入っていない(テストとか用意したら Pull Request 作ります……)ので、motemen/dts-google-apps-script から入手する必要があります。これには vvakame/dtsm解説)を使うのがオススメです。たとえば Spreadsheet および UrlFetch を使いたい場合は、dtsm.json に以下のように書けばよいです。

  "dependencies": {
      "google-apps-script/google-apps-script.spreadsheet.d.ts": {
          "repo": "https://github.com/motemen/dts-google-apps-script"
      },
      "google-apps-script/google-apps-script.url-fetch.d.ts": {
          "repo": "https://github.com/motemen/dts-google-apps-script"
      }
  }

生成

イケイケドンドンで作ったのではっきり言って読みにくいコードですが、https://developers.google.com/apps-script/ にアクセスして必要な情報を取り出した JSON を生成し(spider.js)、それを d.ts に変換する(gen.js)という 2 パスの工程になっています。Byte や Integer などプリミティブっぽい型に関しては、google-apps-script.types.d.ts というファイルだけ手で用意していて、とりあえずコンパイルが通るようにはなっているのだけれど、これであっているのかはあまり分かっていない。

けっこうページがあるのでスロットリングしつつ並列アクセスしつつやるのは面倒だなと思っていたけれど、ES6 Generators を使ってみたら案外すんなり書けた。co を使って、こんな感じに書くと、MIN_WAIT ミリ秒ごとに CONCURRENCY ページずつアクセスするようにできた。GET したページのスクレイピング自体は cheerio を使いました。

function* visit (url) { ... }

co(function* () {
  ...
  while (Scraper.queue.length > 0) {
    var urls = Scraper.queue.splice(0, CONCURRENCY);
    yield Promise.all(
      urls.map((url) => co(visit(url)))
        .concat(new Promise((ok) => setTimeout(ok, MIN_WAIT)))
    );
  }
});

以上

作ってみたはいいものの、どのくらい使い物になるのかはよくわかってません。試してみてくださいね!

TypeScriptリファレンス Ver.1.0対応

TypeScriptリファレンス Ver.1.0対応

Dropbox のファイル選択/保存ダイアログを表示できる Polymer エレメントを書いた

デモを動かしてみるとこんな感じです。

f:id:motemen:20150611202513g:plain

概要

dropbox/dropbox-js を利用してファイル選択/保存ダイアログを表示するコンポーネントです。基本的にフォルダ内のファイルの一覧を行うだけで、それ以上のことはコンポーネントのユーザに委ねているので、ユーザは dropbox-js の API を使って実際のファイルの読み書きを行う必要があります。

使い方

bower でインストールして、

bower install --save motemen/dropbox-file-chooser-dialog

ダイアログを表示したいページや要素で import しつつ、配置します。

<script src="path/to/webcomponentsjs/webcomponents-lite.js"></script><!-- 必要であれば -->
<link rel="import" href="path/to/bower_components/dropbox-file-chooser-dialog/dropbox-file-chooser-dialog.html">
...
<dropbox-file-chooser-dialog app-key="YOUR_APP_KEY"></dropbox-file-chooser-dialog>

API

ドキュメント にある通り、openFolder(path[, mode]) でダイアログを開けます。

var dialog = document.querySelector('dropbox-file-chooser-dialog');

// 「ファイルを開く」ダイアログ
dialog.openFolder('/', 'open');

// 「ファイル名を指定して保存する」ダイアログ
dialog.openFolder('/', 'save');

また簡便のため、dropbox-js へのインターフェースも少し定義してあります。

dialog.authenticate(function (err, dropbox) { ... });

dialog.readFile(path, function (err, content, file) { ... });

dialog.writeFile(file, content, options, function (err, file) { ... });

イベント

ダイアログが表示されて、ユーザによってファイルが選択またはファイル名が指定された時には以下のイベントが発火します。

dropbox-file-chosen-open

ファイルを開く選択。event.detail{ file: Dropbox.File.Stat }

dropbox-file-chosen-save

ファイルを保存する選択。event.detail{ folder: Dropbox.File.Stat, filename: String }

カスタマイズ

  • 必須の属性として、Dropbox に登録したアプリの App Key を app-key に記述する必要があります。
  • with-backdrop 属性を与えることで、デモのようにダイアログの表示時にそれ以外の要素をグレーアウトさせることができます。(詳しくは IronOverlayBehavior
<dropbox-file-chooser-dialog with-backdrop></dropbox-file-chooser-dialog>
  • スタイルシートで dropbox-file-chooser-dialog の width, height を指定することでいい塩梅にダイアログが配置されます。(同上)
dropbox-file-chooser-dialog {
  width: 60%;
  height: 60%;
}
  • iframe 内に表示するなど、遷移による Dropbox 認証が行えない場合、popup-oauth-receiver-url 属性を使うことができます(デモを参照してください)。

また、ヘッダの色はデフォルトで灰色に黒ですが、Custom CSS properties という機構を利用して、以下のようにしてカスタマイズできます。

<style>
:host {
  --dropbox-file-chooser-dialog-header-background-color: red;
  --dropbox-file-chooser-dialog-header-color: white;
}
</style>

上の例は何がしかの Polymer エレメントからスタイルをあてたい場合で、素の HTML から利用するときは以下のように is="custom-style" を指定する必要があります。

<style is="custom-style">
:root {
  --dropbox-file-chooser-dialog-header-background-color: red;
  --dropbox-file-chooser-dialog-header-color: white;
}
</style>

ソースとドキュメント

ソース: https://github.com/motemen/dropbox-file-chooser-dialog

ドキュメントとデモ: https://motemen.github.io/dropbox-file-chooser-dialog/

デモはその性格上お使いの Dropbox の読み書き権限を要求しますが、ファイルの内容の書き換えや読み出しまでは行いません。為念。

初回の認証あたりの流れがちょっといかしてない感じがしますが、どうぞご利用くださいね。

Polymer エレメントの開発ツールと CI

https://blog.polymer-project.org/images/logos/p-logo.png

先日の Google I/O 2015 にあわせて Polymer 1.0 がリリースされました。めでたい。そこで表題のように、自分で Polymer エレメント(コンポーネント)を作るときの構成の話。

始めるにあたっては PolymerLabs/seed-element をベースにすると便利で、この中には以下のような標準的な構成が示されています。

web-component-tester

web-component-tester は Polymer エレメントをテストするためのツールで、テストを実行するだけじゃなく Mocha や Async.js など便利なライブラリをテストから利用できるようにしてくれます。Polymer が提供するコンポーネントのテストはこれに依存しているため、実質的な標準ツールと言ってよいでしょう。

wct コマンドで起動するとローカルでも Chrome、Firefox などを起動して、test 以下のテストをそれぞれのブラウザで実行できます。

f:id:motemen:20150601234654p:plain

iron-component-page

iron-component-page は Polymer エレメントのドキュメントを提供するためのコンポーネントで、body 下に以下のように要素を配置するだけでページの URL から対象のコンポーネントを検出して、それをロードし、API の詳細と、demo ディレクトリがあればデモへのリンクを表示します。Polymer Catalog のようなページがこれだけで作れて、一気にそれっぽさが増しますね。

<iron-component-page></iron-component-page>

この HTML ファイルは基本的にコンポーネントの .html の隣に index.html として置くようです。seed-element をベースにする場合は元からあって、編集する必要もない。

polyserve

上記のドキュメントに関して、bower で入手したコンポーネントや開発中のものをローカル環境で参照するに便利なのが polyserve です。Polymer プロジェクトのルートで以下のようにして起動すれば、bower でインストールしたコンポーネントを http://localhost:8080/components/{element-name} (デモならさらにその下の /demo/ )で参照できます。

polyserve [-p 8080]

seed-element の構成に従うと、プロジェクトルートに置いているコンポーネントの HTML {my-element}.html も、以下のような bower でインストールされる前提の相対 URL 指定で他のライブラリを読みこむことになります。

<link rel="import" href="../polymer/polymer.html">

このため普通のローカルサーバだと参照先がなくて挙動の確認がおこなえないのですが、polyserve はこの要素も /components/{my-element} 以下で配信してくれるので、依存のロードがうまいこといくようになっています。ここが、気が効いていて便利な点。エレメント名には bower.json が参照されます。

ドキュメントの公開

プロジェクトを GitHub にアップロードするのなら、ドキュメントも GitHub Pages を使いたいところです。先ほどの iron-component-page を使えば標準的な UI が提供されるので、それを使います。

polyserve が行うようなディレクトリ構成(みんな /components/ 以下)にするとすんなりいきますが、単純にやるのだと https://{user}.github.io/{element-name}/components/{element-name}/ といった URL での配信になってしまいます。公式のリポジトリには gp.sh ってスクリプトもあるんですが、これはトップページへのアクセスをコンポーネントのディレクトリにリダイレクトするようになっています。Polymer Catalog のように複数のエレメントを配信する場合はそれでいいのですが、1 つだけの場合ちょっと収まりが悪い。

そこで gh-pages ブランチの /index.html に <base href="..."> 要素を置くことで、https://{user}.github.io/{element-name}/ での配信を可能にします。

以上のスクリプトを実行すると components 以下に主役のコンポーネントとその依存をフラットに配置した上で、上記のように細工したドキュメントの index.html を最上位に置いたディレクトリを gh-pages という名前で生成します。この内容を gh-pages ブランチとして push するといい感じになると思います。

vulcanize、polybuild

これで Polymer エレメントを使用したドキュメントページが配信できたわけですが、<link rel="import"> によるインポートは再帰的に行われ、またそのためにネットワーク通信が発生するので結構遅い。これを解決するために、依存するコンポーネントを一枚の HTML にまとめる vulcanize というツールを使うことができます。

vulcanize my-element.html > my-element.build.html

これで HTML も CSS も JavaScript も全部まとまるんですが、まあ全部まとまってもらっても困る(Content-Security-Policy とか)。現在は内部で vulcanize を利用した polybuild があるので、これを使うのがよいということになりそうです(ヘルプがなかったりと、ツールとしての成熟度にはまだ余地がありそう)。

polybuild index.html # index.build.html と index.build.js を生成する

ちなみに Polymer エレメントの自作に関しては以下のビデオを見ると感覚がつかめると思います。0.8 のころの話だけど、大枠は一緒です。

CI

もちろん公開して使ってもらうものであればテストは CI に載せたいし、ドキュメントもウェブでアクセスできるのがいいでしょう。その自動化に今回は Wercker を使います。

Wercker(同僚によると「ウェッキャー」)はいわゆる CI as a Service で、最近 Docker イメージをビルド環境に指定できるようになったらしい。ご無沙汰だったので使ってみました。まあこれはただ使いたかっただけなので、他のサービスでも問題なく応用できると思います。

Wercker でのテスト

wct を使うにはブラウザが必要(ほんとは Sauce Labs も使えるけど、今回はやらなかった)なので、そのための Dockerfile を書きました。motemen/nodejs-java-browsers これは以下がインストールされていて、xvfb-run wct とすればブラウザを起動してテストが行える環境になっています。

  • xvfb
  • chrome
  • firefox
  • nodejs
  • java
  • git

wercker.yaml の当該部分は以下のとおり。

box: motemen/nodejs-java-browsers
build:
  steps:
    - npm-install
    - script:
        name: bower install
        code: |
          ./node_modules/bower/bin/bower install --allow-root --config.interactive=false
    - script:
        name: npm test
        code: |
          xvfb-run npm test

Wercker でのデプロイ

Wercker では成果物を GitHub Pages に push するステップ(手順)が利用可能なので、これと先ほどのスクリプトを利用すれば簡単に GitHub Pages を更新できます。

deploy:
  steps:
    - script:
        name: generate gh-pages content
        code: |
          set -x

          url=$(git config remote.origin.url)
          url=${url%.git}

          name=$(basename $url)
          user=$(basename $(dirname $url))
          user=${user#*:}

          out=./gh-pages

          rm -rf $out
          mkdir -p $out

          cp -R bower_components $out/components

          git archive --prefix=components/$name/ HEAD | tar x -C $out

          git rev-parse HEAD > $out/GIT_REVISION

          cat $out/components/$name/index.html | sed "s:<head>:<head><base href='components/$name/'>:" > $out/index.html
    - lukevivier/gh-pages@0.2.1:
        token: $GITHUB_TOKEN
        basedir: gh-pages

asciidoctor-element

そういうわけでできたのが asciidoctor-element です。どうぞご利用ください(実装は marked-element の丸パクリなんで見るとこない)。

コマンドラインでカラーコードの計算・操作ができるツール

何かしら画面を作らなければいけないときには色のことを考える必要があって、たとえばこの色を少し暗くした色が欲しい! と思ったときに、素人としては頼れる方法を持っていないのが問題なのです。ウェブサイトであれば Scss なり Less なりの CSS プリプロセッサを使えばそういった要求に応える便利な機能が用意されているのであまり考える必要はないのだけれど、他の場面でも使える汎用的な道具が欲しかった。簡単に言うと darken(red, 10%) とか与えたら #rrggbb みたいな形式で表現してくれるやつです。

そこで書いたのがコレだ: motemen/node-less-calc

たぶん Functions | Less.js にある関数がすべて使えます……というので分かるとおり、Less の機能にそのまま乗っかっている非常にエコな実装。オマケで色だけでなく大きさの計算もできる。

% less-calc 'darken(red, 10%)'
#cc0000

% less-calc '1px+1px'
2px

npmjs.org にアップロードしていないので以下のようにしてインストールしてください。

% npm install -g motemen/node-less-calc

2015年のタスク管理

今年に入ってからタスク整理のしかたを考えなおして、とりあえず数ヶ月続けてみた結果、現時点で維持はできていて悪くはないと思ってるやり方をまとめておきます。

大方針: 「やりたいこと」と「やらなければいけないこと」を分ける

これまでは Remember The Milk なり Google Tasks なりに一元管理して、日々生じる外発的なタスク(あの人に声かけて、とか、文書を準備して、とか)と突然思いつく内発的なアイデア(こんなウェブサービス、ツールを作る、○○について調べる)を一カ所に投げ込んでいたのがよくなくて、もちろんツールの機能で分けることはしていたとはいえ、今ひとつ整理された見た目にならなくてだんだん足が遠のいてしまっていた問題があった。というかそもそも整理したくないというのもある。そこで今年はこれらのタスクやアイデアを二つの場所に分けて管理してみることにした。

  • やらなければならないこと、特に締切のあるものは Todoist
  • やりたいこと、やらなくてもいいこと、いつやってもいいことは Trello

という風に分けた。これで基本的には日中は Todoist を見ていて、やる気をだしたいときには Trello を見るという運用になった。

Todoist

ここはやらなければならないタスクを放りこむところ。Todoist はいわゆる TODO 管理サービスで、他の競合と較べたときの長所があるかどうかは知らないのだけれど、なかなか使い心地がよくて、今年のはじめから使い続けている。とうぜんスマートフォンアプリはあるのだけど、OSX アプリがある(Chrome アプリもある)のがよくて、ホットキーから即座にタスクを追加できるのが便利だった。

f:id:motemen:20150420202007p:plain

「締切」のところに「tom」と入力して明日、「mon」と入力して来週月曜日、というのをよく使ってる。また、「プロジェクト」というタスクを分類する機能があるけど、これ系は使いこなせないことがわかっているので、締切オンリーで運用している。また基本的に期限なしのタスクは入れない。

Trello

ここはやりたいことを溜めておくところ。Trello はカンバン式のタスク管理サービス。正直そんなに使いやすいとは思ってないのだけど、タスクの進行状況を一覧できて他サービスとの連携ができるサービスを他に知らないので、前からなんとなく使っていたこれをきちんと使ってみることにしてる。ボードは以下のように分けている。

  • Ideas … なんでもいいので思いついたことが入るところ。ウェブサービスやツールのアイデア、調べ物、おもしろツイートなど。
  • WIP … 着手しはじめた=プロジェクトのディレクトリを作った。
  • To Publish … だいたいできたのでブログに書く。
  • Done … ひと通りおわった。

この運用は去年からしていて、その成果が 【想定はてブ数つき】2014 年のボツネタを一挙公開!!! - 詩と創作・思索のひろば です。

メールは最高

一般的に敵視されがちな感じのあるメールだけど、自分の場合仕事のやりとりに使うわけではなくて、メールは通知の受信用なので、非常に便利だと思うようになった。

Inbox Zero

「Inbox Zero」のオリジナルがどこか知らないのでリンクできないし考え方も本当は知らないのだけど、この名前にしたがって、今年のはじめに受信箱のメールを全部アーカイブした。Gmail は検索でなんでもカバーできるのでそんなに心理的な負担もなく、スッキリしました。また、メールを既読にする際は何かしらのアクションを取る、というルールを設けた。たいてい何か返事をするとか、何もしなくてよいことを確認する、といった風になるけれど、ときどき少し重めであとで確認することにしたい、というものがある。そういう時に、スヌーズ機能のあるメーラが便利。

Mailbox

最近メーラーには Mailbox を使ってる。これが便利なのはメールをアーカイブするだけでなく、「スヌーズ」できる点で、受信箱からとりあえず消し去るけどまたあとで参照したい、というメールを「明日」とか「来週」まで受信箱から外しておくことができる。これで、だいたい一日の終わりには受信箱が空になっている状態にできている。空になるとご褒美画像が見られます。

f:id:motemen:20150420202220p:plain:h400

正直別に使いやすいと思ってはいなくて、Inbox by Gmail でも同じようなことができるし見た目も好きなんだけれど、OSX アプリがあるのが大きく、こちらを使っている。

タスクの追加

上に挙げたようにタスクを置く場所が 2 箇所になったのだけど、スマートフォンから追加するときには、素早く行えるよう IFTTT の Do Note を使っている。

使っているレシピは以下の 2 つ。

タスクを一覧する

前述のように Todoist/Trello とタスクを分けたのだけど、これら以外にも使っているサービスはあるので何かしら集約の手立てを考える必要がある。

Sunrise

Sunrise はカレンダーサービスで、いろいろなサービスと連携できる。これも OSX アプリがある(Chrome アプリもある)。Google カレンダーが表示できるのに加え、Todoist のタスクもカレンダーに表示できるので今日やること、今週やることなんて単位で把握するのに便利。使い出してすぐに Microsoft に買収された

Taco

Taco は TODO 集約サービス。Todoist、Trello だけにとどまらず多くのサービスのタスクを Taco 上で並べることができる(下も参照)。Taco 上で✓すると対応サービスでも完了状態にできるのが便利。このビューでも優先順位付けというかソートができるのだけど、二重管理になるのであまりやっていない。Chrome の新しいタブを Taco にするっていう拡張があって、自然と TODO を目にすることになるのがよい。といいつつ最近は目が滑ってあんまり見てない。

その他の場所で管理されているタスク

Pocket

Pocket はあとで読むサービス。Android のインテントひとつで URL をメモっておくことができるのが便利。これも一種の TODO であるので Taco に表示しておきたいと思ったのだけど未対応だったので、秘密の URL で Pocket の未読を RSS 化できるサービスを作った(Taco はフィードには対応している)。

GitHub Issues

もうひとつ舞い込んでくるタスクは自分の GitHub プロジェクトへのプルリクエストやイシュー。これは把握しているつもりでも見落としてしまっていた問題があったのだけれど、Taco は自分にアサインされたイシューをひとつのタスクとして表示できるので、「GitHub の通知メールをアーカイブする際にはそのプルリクエストやイシューを自分にアサインする」というルールを自分に課すことで、ひとまずその案件については忘れることができた。何かやることを探すモードになったら Taco なり GitHub なりを見ればそのイシューに辿り着けるってわけだ。

以上

とくに

  • タスクのある場所を 2 つ用意する
  • Inbox Zero を目指す
    • スヌーズできるメーラを使う

というのを試してみて、結構気に入ってる。

まだまだ完全に満足はしていなくて、

  • Trello 的な使い方ができてもっとよいもの
  • Evernote のうまい使い方(連携サービスが多いのでうまく使えると楽しそう)

などなど、よりよい知見をお持ちの方は教えてください。

完訳 7つの習慣 人格主義の回復

完訳 7つの習慣 人格主義の回復