2012 年の目標・生活習慣 (第一版)

注意: この内容は改訂されました -> ((<"2012 年の目標・生活習慣 (改訂版)"|URL:http://epa.scitec.kobe-u.ac.jp/~noda/diary/?date=20120108#p01>))

((*年末まで覚えていない「今年の目標」立てなんて単なる儀式にすぎない！*))

ということで、良い目標の立て方に関して聞きかじった知識を動員し、
2012 年の自分の目標 (+α) を設定してみた。

最初に、今年の目標を述べると、

  2012 年 10-12 月平均の 1 日あたり『自発的タスク消化時間』を 2012 年 1-3 月平均よりも 2 時間増やす

である。
そのために、いわば時間の「はかるだけダイエット」をやることにした。
詳しくはこの後で。
いろいろサボるための抜け道は残っているだろうが、
万全を期しているうちに忘れてそのまま立ち消えになりそうなので、とりあえずこれでスタートする。


== 目標設定

=== 1.  去年に問題に思っていたことを解決する内容

* ポイント
  * モチベーションが高いので簡単には放り出さない
  * 人生の目標の一部となるような問題であるのが望ましい

自分はどうも遊ぶのが下手である。
他の人が休日に遊んでいる話を聞いて
「なんであんなに忙しいのにあれこれできるんだ!?」
と羨ましく思う。
それに比べて自分は、ひどい日は、
研究などの自分の作業さえできない日もある。
メールの読み書きやミーティングへの出席だけで一日が終わり、
「研究が進められなかった…」と嫌悪感にかられながら帰宅することもあった。
時間の作り方が下手というか、要領が悪いのだろう。

というわけで、
趣味の時間や自分自身の作業の時間を作るのを目標にした。
このあと、もう少し練っていく。

=== 2. 客観的、計測可能

* ポイント
  * 達成したか否かが一発で分かる
  * 自分ひとりでは誤魔化しにくい

他者の視点から判断できる、客観的な目標を立てよという話を聞く。
よく挙げられる例としては、資格の合否や点数。
自分の場合は、「自発的なタスクをこなせた時間」を予め定義して
機械的に計ることにした。
「自発的なタスク」とそうでないタスクの定義は以下のとおり。
実際には分類に苦しむものもあるが、こういう方向性、ということで。

==== 「自発的タスク」とは

「やりなさい」「やるべき」とは言われてなかったり、
明確な締め切りがなかったりして、
放っておいたらそのままズルズルとうしろに行ってしまうもの。
重要だけど緊急ではないタスク。準備時間も含む。

* ランニング
* 研究活動
* 研究以外の勉強
* 読みたい本の読書
* 行ってみたい場所に行く

==== 「自発的タスク」ではないタスクとは

「やりなさい」「やるべき」と言われているもの。
締め切りがあって、放っといたらつつかれるなり、怒られるなりするもの。
緊急だけど重要とは限らないタスク。準備時間も含む。

* メールチェック
* 参加必須のミーティング、セミナー
* いろいろな当番
* 学会発表やその準備

=== 3. 他者の都合に左右されにくい

* ポイント
  * 人のせいにしづらい条件にすることで、安易に放り出さないようにする

スケジュールは他人の都合に結構左右される。
割り込みタスクを完全に排除するのは不可能。
ということで、割り込みタスクは折込済みで計測、比較する。
また、「○時間」という絶対的な時間で目標を立てるのではなく、
「10-12 月の平均が 1-3 月の平均に比べて○時間長い」という相対的な目標にした。
3 ヶ月平均にしたのは、結果をならすため。
たとえば 12 月だけで判定するようにしていると、
その月に偶然割り込みタスクが多く入っただけで目標達成が困難になるからである。

日々の生活を改善するのが本来の目的なので、
細かい数字にはこだわっても仕方がない。

== 4. 実現可能性は高すぎず低すぎず

* ポイント
  * 程よい緊張感をもたせる

とりあえず、
10-12 月は 1-3 月に比べて「自発的タスク」消化時間を 1 日あたり 2 時間増やす、とした。
2 時間という数字には根拠はない。
主観的に、明らかに達成不可能ではないが、ちょっとしたズルでは達成できない量は
この程度かな、と思ったにすぎない。
これは 1 ヶ月くらい統計をとってみて、手応えをもとに修正するかもしれない。


== 目標を忘れないようサポートする行動

目標を立てただけだと忘れたりするので、
サポートする仕組みをつくる。

=== 1. 公言する

公言することには賛否両論あるらしい。
公言することで、半分達成したかのような気分になってしまうのでやらなくなる、という意見もあるようだ。
ここでは「なかったことにしづらくなる」効果が大きいと思って公言する。
自分ひとりだと「ま、いっか」で闇に葬るのは必至だろうし。

具体的にはこの場で発表している。
また毎週、「週次レポート」を公開することにする。

=== 2. 忘れない仕組みを作る

「週次レポート」を出すのを忘れたら意味がない。
ということで、自分宛にリマインドメールを定期的に送るようにしておく。
リマインドメールにはこのブログの URL も書いて簡単に見直せるようにする。

=== 3. 計測の手間を減らす

「週次レポート」の集計が面倒だと
「今週は忙しいのでまたあとで」と逃げるかもしれない。
これはプログラムによる自動集計、レポート自動生成を予定している。
具体的には以下を考えている。

==== 計測方法

タスク管理サービス Toodledo で一日を回す訓練を続けていることを前提とする。
12 月一杯は続けられたので、三日坊主になることはないだろう。

* 「自発的タスク」には Toodledo で特定のタグをつける
* 一日に一回、その日に実行できた「自発的タスク」を自動で取得、解析
  * 一日に、当初予定していたタスクの実行率は?
  * 「自発的タスク」の実行率は?
* 一週間に一回、「週次レポート」を自動生成し、自分や web に投げる

=== 4. 罰を設定するなど、やらないでいられないようにする


自動投稿ができる場合は意味がないが、
手動で投稿することにした場合は、
忘れたら研究室の飲み物代に 100 円寄付するなどを設定するかもしれない。

あえて結果を手動で投稿する仕組みにすることで、
悪い結果を恥じる心理的罰を与えることも考えている。
でもこれは投稿しなくなるきっかけにもなるので諸刃の剣か。
「今日は週次レポートの発表日です」だけ自動投稿にして
逃げられないようにするのもありかな。


== その他

=== その他、目標達成を支援しそうなこと

はかるだけダイエットは、はかっているだけでは痩せない。
ということで定常的に以下を行う。

* 各作業の見直し、高速化
  * 作業手順書やチェックリストの作成、見直し
* Toodledo の毎日のメンテナンス
  * 睡眠時間も含め、1 日の行動時間が 23 時間程度に収まるようにする

=== とりあえずやった/やること

今後の具体的行動は以下のようになる。

* 完了
  * 今後一週間、各日のタスク量を計算するプログラム作成
  * 上記プログラムを利用して毎日自分にタスク調整を促すレポートが来るように cron  設定
* 今週から来週
  * 週次レポートの自動集計システムの作成と設置
  * 1/7 (土) に最初の進捗状況 or 週次レポートを公開する
* 1 月中
  * 計測結果をみて目標を微修正する

以上。

[toodledo][ruby] Toodledo API version 2.0 の使い方

== 概要

タスク管理サービス
Toodledo http://www.toodledo.com/
の API version 2.0 を使う方法のメモです.
基本的には Toodledo の

Developer's API Documentation : Version 2.0
http://api.toodledo.com/2/account/index.php

をもとにしていますので, 詳細を知りたい場合はそちらを参考にしてください.
これ以降に引用しているページは全てこのドキュメントの中のページです.

実行環境には Debian GNU/Linux 6.0 (squeeze),
サンプルコードには Ruby を使っています.

== 認証の流れ

最初に認証の流れを概説します.

* 新たにアプリケーションを作るときだけ行えばいいこと
  * Toodledo のサイトでアプリケーションの登録をし, app ID と app token を取得する
  * user ID と app token から signature を求める

* 4 時間に 1 回必要
  * user ID, app ID, signature を Toodledo のサーバに送信して session token を取得する
  * ユーザの password, app token, session token から key を求める

* Toodledo のサーバへの問い合わせのたびに必要
  * 問い合わせ内容に key を添付する

詳細は
Authentication http://api.toodledo.com/2/account/index.php
が参考になります.

== アプリケーションの登録

API を使うためには,  作るアプリケーションごとに登録が必要です,
バージョンアップだけなら登録しなおす必要はありません.

Toodledo にログインした状態でブラウザで
Register & Stats http://api.toodledo.com/2/account/doc_register.php
に行きます.
以下の項目を記入し, "Register" ボタンを選択.

* Desired AppID
* Product Name
* Website
* Email Address
* Category (プルダウンメニューから選択)
* Short Description
* Long Description
* Icon (設定は任意)
* State (とりあえずは In Development / Beta)

うまくいけば
app ID と app token が発行されます.
後から確認・編集するには再び
Register & Stats http://api.toodledo.com/2/account/doc_register.php
にアクセスして, ページの下のほうにある一覧表から行います.

== signature の計算

Authentication http://api.toodledo.com/2/account/index.php
より, signature の計算式は以下のとおりです.

  sig = md5( userid + appToken )

ここで userid は Toodledo の通常のタスク管理のページの "setting" に書かれている "Unique ID" のことです.
また, md5 は与えられた文字列の MD5 ダイジェストを返す関数を意味します.

自分のプログラムの結果が正しいかどうか調べたい場合は,
Authentication http://api.toodledo.com/2/account/index.php
のページの上から 2 割くらいの場所に "Testing" という名前で
テキストボックスが二つある場所で答え合わせができます.

もしくは md5("test") の結果が
"098f6bcd4621d373cade4e832627b4f6" になることを確認してもよいでしょう.

== session token の取得

session token を得るためにサーバに問い合わせます.

Sync & Rate Limiting http://api.toodledo.com/2/account/doc_sync.php
によると, session token の取得は 1 時間に 10 回までという制限があります.
ただしひとつの session token は 4 時間の間は使い回せます.
同一ユーザは 1 時間に最大 250 回まで問い合わせることができます.

方法の詳細は
Connecting & Encoding http://api.toodledo.com/2/account/doc_encode.php
が参考になります.
ここでは JSON 形式で記述して http の POST メソッドで問い合わせることにします.
SSL はプロアカウントでないと使えないようです.

Ruby の JSON ライブラリのインストールは以下でできます.

  $ sudo gem install json

Toodledo には以下のような文字列を送ることになります.
vers, device, os は省略可能です.

  http://api.toodledo.com/2/account/token.php?userid=abcdef1234556789&appid=myAppID&vers=21&device=iphone4&os=401&sig=a1s2d3f4a5s6d7f8a9s0d

サーバが返した結果を JSON 形式のまま表示させると

  {"token":"1a2b3c4d5e6f7"}

のような形になっています.

== key の作成

毎回の問い合わせの際に用いる key の計算式は
Authentication http://api.toodledo.com/2/account/index.php
より, 以下のとおりです.

  key = md5( md5(userPassword) + appToken + sessionToken )

これも
Authentication http://api.toodledo.com/2/account/index.php
のページの上から半分くらいの場所の,
テキストボックスが三つある場所で答え合わせができます
(生 password 入れさせられるのでおすすめしませんが).

これで準備が整いました.

== サンプルコード

参考までに, key を得るまでの Ruby のコードを示します.
以下では簡単のため session token の使い回しは行っておらず,
スクリプトが実行されるたびに取得し直されます.
また, ログインパスワードは早い段階で md5 を通しているので
key を計算する行の内容はさきほど挙げたものとは少し違います.

  require 'rubygems'
  require 'digest/md5'
  require 'json'
  require 'uri'
  require 'net/http'
  Net::HTTP.version_1_2
 
  # MD5 digest を返す
  def md5(str)
    Digest::MD5.hexdigest(str)
  end
 
  # url に JSON 形式の body を http で post し,                                
  # 受け取ったデータの body (JSON 形式) を hash に parse して返す
  def post_server(url, body)
    response_hash = nil
    uri = URI.parse(url)
    Net::HTTP.start(uri.host, uri.port){|http|
      response = http.post(uri.path, body)
      response_hash = JSON.parse(response.body)
    }
    response_hash
  end
 
  # session token の取得に必要な signature の生成
  def gen_signature(userid, apptoken)
    sig = md5( userid + apptoken )
  end
 
  # session token の取得
  def get_session_token(url, appid, apptoken, userid)
    sig = gen_signature(userid, apptoken)
    body = "userid=#{userid}&appid=#{appid}&sig=#{sig}"
    token = post_server(url, body)["token"]
  end
 
  # 通常の問い合わせに必要な key の生成
  def gen_key(md5_password, apptoken, session_token)
    key = md5( md5_password + apptoken + session_token )
  end
 
  SESSION_TOKEN_URL = "http://api.toodledo.com/2/account/token.php"
  APPID = YOUR_APPID    # ブラウザでアプリを登録する際に取得
  APPTOKEN = YOUR_APPTOKEN    # ブラウザでアプリを登録する際に取得
  USERID = YOUR_USERID    # setting の Unique ID
  PASSWORD = YOUR_PASSWORD    # ログインパスワード
  MD5_PASSWORD = md5(PASSWORD)

  session_token = get_session_token(SESSION_TOKEN_URL, \
                                      APPID, APPTOKEN, USERID)
 
  p key = gen_key(MD5_PASSWORD, APPTOKEN, session_token)



== 実行例: タスクの取得

実行例として,
Tasks http://api.toodledo.com/2/tasks/index.php
の "Retrieving Tasks" を例にタスク取得について解説します.
他の操作も同じ要領です.

session token の取得の要領で, たとえば以下をサーバに送信します.
以下は unix time で 1234567890 以降に更新されたタスクのみを
folder,star,priority も含めて要求する命令になります.
id, title, modified, completed は常に返ってくる仕様です.

  http://api.toodledo.com/2/tasks/get.php?key=YourKey&modafter=1234567890&fields=folder,star,priority

注意: session token を取得したときと POST する先が違います!

以下のようなデータが返ってきます.
最初に num (取得できたレコード数), total (サーバでヒットしたレコード数) で構成されたレコードがあり,
後は要求した内容のレコードが並んでいます.

  [{"num":"2","total":"2"}, {"id":"1234","title":"Buy Milk","modified":1281990824, "completed":0,"folder":"5409195","star":"1","priority":"-1"},{"id":"1235", "title":"Fix flat tire","modified":1280877483,"completed":1280808000, "folder":"0","star":"0","priority":"0"}]

データの読み方は
Tasks http://api.toodledo.com/2/tasks/index.php
の "Task Datatypes" などを参照してください.

意義なんか気にせずにやっていたら意義が見つかる?

最近自分の目にちょくちょく飛び込んできている主張に

  多くの人がブログなどで自分の意見を公開するのをためらう理由のひとつとして、
  自分の考えがありふれたものであって公開するに値しない、と思ってしまうことがあるけど、
  じつは自分が普通だと思っていても他人から見たら全然普通ではないんだよ。
  だから気にすることなく発信したらいいよ。

というのがある。
ぱっと探せたものだと以下のような記事。

【「普通」を武器にする！自分レベルアップ術】「普通」を発信することを恐れない
http://www.ashi-tano.jp/?p=586

あなたにとって当たり前のことが他人にとっては驚くべき事である - GIGAZINE
http://gigazine.net/news/20111213-obvious-to-you-amazing-to-others

自分が普通だと思っていても他人から見たら普通じゃないことがある、というのは
たとえばテレビでケンミンショーを見れば感じることができる。
自分の出身地域の「普通のこと」に
東京のスタジオが「えーーーーっ！？」と言っているのを見て、逆に驚くはず。

で、ここで立ち止まって、
自分で普通だと思っていても発信できている人ってどういう人だろうと考えてみた。
考えついたのは二種類。

冒頭の記事のように、
自分の考えが普通じゃないこともあるかもしれない、と自覚して
発信している人もいるだろう。

あともうひとつ。
普通であろうがなかろうが発信というか、表現そのもののが好きな人がいるだろう。
後者は巧拙はさておき、表現自体が好きなのだろう。

で、さらに考えてみると、
「自分の意見は意外と普通じゃない」と気づいた人は
後者の「表現そのものが好きな人」が多いのではないかと勝手に思った。
普通だと思ったことも発信すれば、自分が普通だと思ったことに
他人がすごいと思った、というフィードバックをもらいやすいからだ。

まとめると
「発信の意義を気にせず、好きでたくさん発信していたら発信の意義に気づいた」
ということか。

[memo]技術メモを一挙公開

これまで書きためていた技術メモを一挙公開しました.

http://epa.scitec.kobe-u.ac.jp/~noda/memo/

書きためていたメモの中に公開不可能なものが混ざっていたため,
公開可能な部分を取り出すのが面倒で放置していたのだが,
思い立って分別, 公開した.

あくまでも自分用メモが外から見えるだけ, というスタンス.
気が向いたら整理します.

非公開ものも含めたらテキストで 55KB あった.
継続はなんとかかんとか.

学生時代の「余命」

後輩たちの行動に学んだ。

年度末がどんどん近づき、卒論・修論の締め切りはどんどん近づいてくる。
当然研究が忙しくなってくるわけだが、彼らは遊ぶのをやめない。
というよりむしろ睡眠時間を削ってでも普段よりたくさん遊んでいるように見える (のは気のせい?)。
そこには「社会人になったら遊べなくなるから今のうちに遊び倒しておく」というようなセリフがちらほら。

ああそうか、これは「余命」の過ごし方と一緒だ。と気づいた。

自己啓発本には
「もし自分の余命があと半年しかなかったらどうするか？」
といった質問がよく登場する。
この質問は読者が本当にやりたいことを洗い出すためのトリガーなのだけど、
彼らはこれの回答を地で実践しているように見える。
学生時代の「命」が尽きるのに向かって全力で走っているよう。

この勢いならば、彼らは人生の終わりの際も悔いを残すことはないだろう、とすら思えた。

自分も見習いたい。

[ruby][twitter] 任意の公開ユーザのツイートを取得する

過去のツイートを加工したくなったので、
任意の公開ユーザのツイートを取得する ruby スクリプトを作ってみた。
予め

The Twitter Ruby Gem
http://twitter.rubyforge.org/

をインストールする必要がある。

 require 'rubygems'
 require 'twitter'
 require 'time'

 ID = USERID   # ツイートを取得したいユーザの ID
 COUNT = 20    # 一度に取得するツイート数. 最大値は 200.

 tweets = Twitter.user_timeline(ID, {:count=>COUNT, :page=>1})
 tweets.each do |t|
   puts "#{t.created_at.strftime("%Y/%m/%d %H:%M")} #{t.text}"
 end

公開されているものを読み込むだけなので結構短く書けた。

200 より大きい数のツイートを取得したい場合は
user_timeline の :page の数字を変えていけばよい.

== 参考ページ

tweet のバックアップ
http://kurano.net/text/id/12717045263.html

[lifehacks]ウェブサービスと非常勤の秘書

ウェブサービスにタスクやスケジュールを預けるのに
抵抗を抱いていた時期がある。
たとえば、そのサービスがずっと続く保証はないし、
もしかすると突然使えなくなるかもしれない。
果たしてそんなものにタスクやスケジュールを預けてよいものか、と。

今は、そういうサービスは秘書と同じような存在だと考えている。
たとえば秘書を雇うとすると、
秘書にはそんなに抵抗なくタスクやスケジュールを任せるだろう。
いつまで勤めているか保証されないのに、である。
真面目な人であっても、急病や事故で突然仕事ができなくなることだってある。

そんな万が一の場合に備えて、
いつでも次の人あるいは自分に引き継げるようにしておくことになる。

サービスにも同様に接していて、
急に止まっても泣かないようにバックアップを取っているし、
そもそもバックアップの取りづらいサービスは使わないようにしている。

また、万人単位でユーザのいるサービスが突然休止して二度と動かないことは滅多になく、
たいていは休止するとしても何ヶ月か前に予告があるので
その間に対策を考えればいいと楽観的に考えている。