2012年9月8日土曜日

同じ容量・規格の microSD でもメーカーにより 100 倍以上速度が違うケースがあった


(ベンチマークソフトの生データは記事末尾にまとめてあります)

この記事を書くきっかけは、電子書籍リーダー kobo touch の内部ストレージを
2GB から 32GB に交換したことにありました。
kobo touch の内部ストレージは microSD なので、
ストレージの入れ替えってそんなに難しくないんですよね。
詳しいことは以下のブログなどを参考にしてください。
もちろん、保証はなくなりますので自己責任でどうぞ。



私は 32GB, class10 のノーブランドの microSD を買い、交換しました。
するとどうなったか。

ページ遷移がめちゃくちゃ遅くなった!

なんでやねん!
class10 なので読み取り速度は速いんじゃないのか?

頭にきたので手元の microSD などをかき集めてベンチマークを取ってみました。
Windows 7 上で CrystalDiskMark 3.0.1 というソフトを使いました。

ここで注意です。
CrystalDiskMark の動作を眺めていて気づいたのですが、
このソフト、複数回計測した場合は最大の値を採用するようです(せめて中央値にしようよ...)。
しかも、Random Read/Write の場合は
1回目が他の回よりも桁で大きいスコアを出していたこともあるので
キャッシュが効いているか否かがスコアに如実に影響しているとおもいます。
この点を留意したうえで以降の記事を御覧ください。

最初に結果をまとめると、

・Random Write、とくに小さなサイズ (ここでは 4 KB) のファイルを書き込みする場合はメーカーによって差が大きい。最高と最低で 100 倍以上スコアが違うケースがあった。
・それ以外 (Sequential Read, Sequential Write, Random Read) は各メーカーでそんなに差はない。せいぜい 2 倍以内。


で、それから導いた結論は、

携帯や kobo のように小さいファイル(数 KB 単位)の書き込みを行う場合は、メーカーやブランドによって性能に大差が出る可能性がある
・デジカメのように、比較的大きなファイル(MB 単位)を書き込む場合はノーブランドでもあまり変わらなさそう

です。


例として 4(+1) 社の "32GB, class10" の microSD の
Random Write 4KB (QD=1) の結果です。
(他のデータは記事末尾につけています)

1位 Gigastone 1.123 MB/s
2位 SAMSUNG 0.624 MB/s
3位 PATRIOT 0.008 MB/s
4位 ADATA  0.006 MB/s

参考 Sandisk 1.317 MB/s (これだけ UHS Speed Class 1 という規格) 

2位と3位の違いはなんでしょうか......。
しかも、Gigastone という私のよく知らないメーカーが1位になってしまいました。
たしかこれ、ノーブランドとして格安で買ったはずなんですけど。

kobo にはそれまで ADATA を入れていたのですが、
もしやと思って Gigastone のに入れ替えてみました。
すると、ページめくりがさっきより速くなりました
(100 倍速くなったわけではないです。別の箇所が律速なのでしょう)。
kobo はページをめくるたびに
何かの小さいファイルを書き込みしているのかもしれません。

というわけで皆さん、microSD(おそらく SD も)を買うときは
規格だけでなくメーカーやブランドにも気をつけましょう。
私も今後はノーブランドは避け、
「ベンチマークソフト」と「買おうとしているブランド」で
検索をかけてから買おうと思います。

以下、資料編です。

上記 4(+1) 枚に加えて、それ以外のサイズや規格、異なったデバイスについて
CrystalDiskMark が出力したデータを貼り付けておきます。
特記がないものは全て microSD です。

共通情報

-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]


(ここの結果はメディアによって異なる)

  Test : 1000 MB
    OS : Windows 7  SP1 [6.1 Build 7601] (x64)


Gigastone 32GB, class10

           Sequential Read :    21.886 MB/s
          Sequential Write :    12.915 MB/s
         Random Read 512KB :    20.860 MB/s
        Random Write 512KB :    10.902 MB/s
    Random Read 4KB (QD=1) :     3.599 MB/s [   878.7 IOPS]
   Random Write 4KB (QD=1) :     1.123 MB/s [   274.2 IOPS]
   Random Read 4KB (QD=32) :     3.387 MB/s [   826.8 IOPS]
  Random Write 4KB (QD=32) :     0.826 MB/s [   201.6 IOPS]

PATRIOT 32GB, class10

           Sequential Read :    22.380 MB/s
          Sequential Write :    11.184 MB/s
         Random Read 512KB :    21.150 MB/s
        Random Write 512KB :     0.942 MB/s
    Random Read 4KB (QD=1) :     4.610 MB/s [  1125.5 IOPS]
   Random Write 4KB (QD=1) :     0.008 MB/s [     2.0 IOPS]
   Random Read 4KB (QD=32) :     5.259 MB/s [  1284.0 IOPS]
  Random Write 4KB (QD=32) :     0.008 MB/s [     2.0 IOPS]
  

ADATA 32GB, class10

           Sequential Read :    22.184 MB/s
          Sequential Write :    19.169 MB/s
         Random Read 512KB :    21.803 MB/s
        Random Write 512KB :     0.740 MB/s
    Random Read 4KB (QD=1) :     5.495 MB/s [  1341.4 IOPS]
   Random Write 4KB (QD=1) :     0.006 MB/s [     1.5 IOPS]
   Random Read 4KB (QD=32) :     5.756 MB/s [  1405.2 IOPS]
  Random Write 4KB (QD=32) :     0.006 MB/s [     1.5 IOPS]

SAMSUNG 32GB, class10

           Sequential Read :    22.225 MB/s
          Sequential Write :    12.029 MB/s
         Random Read 512KB :    20.302 MB/s
        Random Write 512KB :    10.766 MB/s
    Random Read 4KB (QD=1) :     4.981 MB/s [  1216.1 IOPS]
   Random Write 4KB (QD=1) :     0.624 MB/s [   152.2 IOPS]
   Random Read 4KB (QD=32) :     5.025 MB/s [  1226.9 IOPS]
  Random Write 4KB (QD=32) :     0.628 MB/s [   153.4 IOPS]

Sandisk 32GB, class10 (UHS Speed Class 1)

           Sequential Read :    40.941 MB/s
          Sequential Write :    12.961 MB/s
         Random Read 512KB :    41.222 MB/s
        Random Write 512KB :    14.347 MB/s
    Random Read 4KB (QD=1) :     4.634 MB/s [  1131.4 IOPS]
   Random Write 4KB (QD=1) :     1.317 MB/s [   321.6 IOPS]
   Random Read 4KB (QD=32) :     4.238 MB/s [  1034.8 IOPS]
  Random Write 4KB (QD=32) :     0.844 MB/s [   206.2 IOPS]

ノーブランド 2GB, class不明 (携帯のおまけ)

           Sequential Read :    20.733 MB/s
          Sequential Write :    11.533 MB/s
         Random Read 512KB :    20.210 MB/s
        Random Write 512KB :     1.842 MB/s
    Random Read 4KB (QD=1) :     4.357 MB/s [  1063.8 IOPS]
   Random Write 4KB (QD=1) :     0.032 MB/s [     7.9 IOPS]
   Random Read 4KB (QD=32) :     4.251 MB/s [  1037.9 IOPS]
  Random Write 4KB (QD=32) :     0.021 MB/s [     5.2 IOPS]

Sandisk 2GB, class不明 (kobo touch の内部ストレージとして入っていたものを FAT32 にフォーマットし直した)

           Sequential Read :    19.428 MB/s
          Sequential Write :     7.966 MB/s
         Random Read 512KB :    18.568 MB/s
        Random Write 512KB :     1.750 MB/s
    Random Read 4KB (QD=1) :     3.185 MB/s [   777.7 IOPS]
   Random Write 4KB (QD=1) :     0.063 MB/s [    15.3 IOPS]
   Random Read 4KB (QD=32) :     3.027 MB/s [   738.9 IOPS]
  Random Write 4KB (QD=32) :     0.057 MB/s [    14.0 IOPS]

ノーブランド SD 32GB, class 10

           Sequential Read :    21.448 MB/s
          Sequential Write :    17.606 MB/s
         Random Read 512KB :    21.689 MB/s
        Random Write 512KB :     0.612 MB/s
    Random Read 4KB (QD=1) :     4.484 MB/s [  1094.8 IOPS]
   Random Write 4KB (QD=1) :     0.005 MB/s [     1.3 IOPS]
   Random Read 4KB (QD=32) :     4.556 MB/s [  1112.4 IOPS]
  Random Write 4KB (QD=32) :     0.005 MB/s [     1.3 IOPS]

VAIO Z21 の SSD (2 台で RAID0)

           Sequential Read :   878.082 MB/s
          Sequential Write :   117.238 MB/s
         Random Read 512KB :   404.977 MB/s
        Random Write 512KB :   241.832 MB/s
    Random Read 4KB (QD=1) :    16.151 MB/s [  3943.1 IOPS]
   Random Write 4KB (QD=1) :    39.692 MB/s [  9690.5 IOPS]
   Random Read 4KB (QD=32) :   197.002 MB/s [ 48096.3 IOPS]
  Random Write 4KB (QD=32) :    93.460 MB/s [ 22817.4 IOPS]

2012年8月4日土曜日

悩まずに夏休みの自由研究を終わらせる方法

小学生の頃の宿題で、頭を悩ませていたのが自由研究であった。
その名の通り、テーマが自由であったので何をしたらよいのか分からなかったからである。
何日の頭を悩ませ、そして何日もかけてああでもないこうでもないと書きあぐねるのは
本当に苦痛であった。

というわけで、当時の自分にアドバイスするつもりで
簡単なテーマの決め方、作業の進め方を提案しようと思う。

テーマの決め方


休み中に行った旅行先について調べることにすればよい。
資料の収集は簡単だし、実体験したものについて書くことは
作業量のわりに教師の受けがよい、という個人的経験があるからである。

準備(旅行中)


資料は旅行中にほとんどまかなえる。
有名な場所の写真はバシバシとっておく。
無料のパンフレットがあれば片っ端から集めておく。
旅行中はひたすら収集に専念する。
選り分けだすと考えこんでしまって旅行が楽しくなくなるからだ。

準備(帰宅後)


家に帰ったら、有名な場所やイベントのうちトップ 10 を選び出し、
それに関する資料を一箇所にまとめておく。
まとめたものを、レポートを書くときに使う。

レポート執筆(1枚のポスターに書く場合)


いよいよレポート執筆である。
ポスター用紙の場合は、
タイトルと「はじめに」と「おわりに」を書く場所を確保した上で、中央に大きく略地図を書く。
その上に写真を貼り付けて、横に写真や場所の説明を書く。
パンフレットがあればその文章を参考にしたり、切り抜いて貼ってもよいだろう。
資料の不足に気づいた場合は、検索で補う。
そこに行った人のブログは結構参考になる。
「はじめに」は、夏休みに旅行に行ったのをきっかけに興味を持ったので調べてみた、でよいだろう。
「おわりに」は、何ヶ所かのお気に入りの場所を褒めたうえで、また行ってみたいとか、こういう自然(街並み)がずっと続けばいいと思った、とか書けばよい。

レポート執筆(レポート用紙に書く場合)


書く内容はポスターの場合と一緒で、構成が違うだけである。
目次に略地図を書けばよい。
あとは各場所の説明を1箇所1ページで書いていけば良い。


作業は以上である。
さっさと作業すれば半日くらいで出来るはずである。
さあ、浮いた時間で本を読んだり、遊びに行ったりしよう。

傘の端にある突起の危険性

自分のさした傘や日傘に注意を払わない人を見るたび、
傘の端の尖った部分のない傘ができて流行らないかな、と思う。

歩きタバコの火は子供の目の高さ、と言うけど、
傘から出た突起部は大人の目の高さなわけで。事故があってもおかしくない。

ただ、傘が関わる事故全体からすると、どうやらマイナーな事故であるようだという印象だ。
「傘 事故」「傘 失明」でググったら、
傘の端の突起での事故の話はあるものの
それほどの数は見つからない。
主に出てくるのはジャンプ傘の不良での事故、
傘をさしながらの自転車運転での事故、振り回した傘が目に入った、など。

2012年7月10日火曜日

携帯で撮った写真をブログに貼るまでの試行錯誤 (2) Evernote ヴィジェットの落とし穴

前回Dropbox, Eye-Fi を使って
携帯で撮った写真をクラウドに自動同期するまでを設定しました。

ところが、一部の写真は同期されないのです。
どうやら、Evernote のカメラヴィジェットで
撮った写真は根こそぎダメでした。


Evernote のカメラヴィジェットは何かというと、
撮った写真をただちに Evernote のノートとして送れる機能です。
iPhone での FastEver Snap のような使い方をしていました。

同期されない原因を調べてみると、
Evernote のカメラヴィジェット経由で撮影したときの
写真の保存場所の違いにありました。

私の持っている DIGNO (ISW11K) の場合は
普通の写真は /DCIM 以下にありますが、
Evernote のヴィジェットで撮った写真は
/Evernote/unsaved_notes/ENIMAGE*.jpg として保存されていたのです。

そこで、上記の Evernote 領域にあった写真を /DCIM にコピーしたところ、
同期が始まりました。

これを定期的にやるのは面倒なので、思いきって
Evernote での写真管理をやめてしまおうかとも思っています。

代わりに写真は普通のカメラアプリで撮って Dropbox による同期に任せるのです。
今のところ Evernote に保存した写真はほとんど見返していないし、
写真は写真集などの見やすい形で別途保存したほうが
見返したり活用したりする可能性が高くなるかもしれないと考えています


2012年7月9日月曜日

携帯で撮った写真をブログに貼るまでの試行錯誤 (1) 携帯からクラウドへの自動アップロード

ブログに写真を貼るのが面倒なので、
ほとんどの記事は文章だけで済ましています。

写真やイメージのイラストを貼ったほうが見栄えはいいのでしょうけれど、
これの面倒さがもとでブログを書かなくなるのは本末転倒なので

とはいっても私は風景の写真を撮るのが好きで
そういう話題を記事にしたいこともあります。
さっきの摩周湖の記事などですね。

そんなわけで、撮った写真を大量にブログに貼り付けるまでのシーケンスを
簡単にできないものか試行錯誤しているところです。

とりあえず、上流から攻めることにして、
携帯のカメラをネットワーク上に自動アップロードすること、
および PC への自動同期を試しています。

今のところ、携帯では下記の二つの Android アプリを試しています。
どちらもアカウントを作ってアプリを設定することで、
撮った写真を自動的にクラウドへアップロードしてくれます。
また、PC にクライアントソフトを入れることで PC への同期も行われます。

今のところは Dropbox が優勢です。

携帯からクラウドまでのアップロードは両者拮抗しているのですが、
PC 側のクライアントにデータが転送されてくるのは
Dropbox がほとんどライムラグなく開始するのに対し
Eye-Fi は数時間遅れでした。
こちらの設定が甘い可能性は残っています。

また Dropbox は、他の同期したいファイルと一元化できる分、管理は楽でしょう。


一方で Eye-Fi の良いところは、
自動で撮影日ごとにフォルダ分けしてくれることです。


Dropbox もファイル名を撮影日時にリネームしてくれるのですが、
「カメラアップロード」フォルダにフラットに並んでいるので
「あの日の写真が見たい」という時に
探すのにちょっと時間がかかるのが難点ですね。
ただ、撮影日でのフォルダ分けくらいならば、
適当なスクリプトを書いて cron で回せばカバーはできます。

2012年7月8日日曜日

霧のない摩周湖を見てしまうと...

先日、北海道の摩周湖に行って来ました。
「霧の摩周湖」と呼ばれるくらい霧が多い場所だそうですが、
運良く、霧のない状態を見ることができました。



ところで、霧のない摩周湖を見ると

    男性は就職できなくなる
    女性は結婚できなくなる
    カップルは別れる

という噂があるそうです。

一説には、ツアーのガイドさんが
霧のあるときにツアーで来てしまったときに
客を慰めるために考えだしたのが広まったとか。

2012年7月7日土曜日

楽天 kobo を予約した!

電力をほとんど使わない電子ペーパーを応援しています。
貧乏性なので、普通のディスプレイをつけっぱなしにしていると
電池がどんどん消耗されていく気がして落ち着かないんですよね。

既に Kindle DX を個人輸入して使っているのですが、
Amazon.com の管轄なので日本語の本は買えません。
基本的に省電力の PDF リーダーとして使っています。

さて、最近 Kindle と楽天 kobo が日本に進出することが話題になっています。
これまで買った本はもっぱら自炊していたのですが、面倒くさすぎる。
時間と手間ががもったいないので、
紙の本より少しくらい高くても買うんだけど、と思っていました。

Kindle か kobo か、あるいは別の端末か、
しばらく様子を見るという手段もあったのですが、
楽天の 3000 ポイントバックのキャンペーンに釣られて
kobo を予約しました。

電子ブック楽天<kobo>: 読書に革命を。新しい楽しさを。
http://kobo.rakuten.co.jp/event/camp-point/


安いという以外にも、ゲーミフィケーション機能があるのにも注目しています。
最近読書をする習慣がなくなっていたのですが、
これをきっかけに習慣を取り戻して
もっと本を読めるようになれば、と他力本願でいます。

2012年7月6日金曜日

旅先の温泉が苦手な理由

私は「旅先で温泉」に良い印象を持っていない。
風呂は嫌いではないのだけれど。

なんでだろうと考えてみると、
小学校のときの林間学校まで遡れた。

林間学校でのお風呂は交替制で、時間は 15 分と決められていた。
ただでさえ落ち着けない上に、
湯が熱く、上がっても汗がなかなか引かない。
しかし早く服を着て次の班に明け渡さないといけないから、そのまま服を着る。
下着が汗でびしょ濡れで気持ち悪いのがとても嫌だった。

ぬるめの風呂が好きな私には、たいていの温泉は熱すぎて落ち着かない。
さっと入って水のシャワーを浴びたら出ていってしまうことが多い。

2012年7月5日木曜日

家の近所でもできるけどやったことがないことは、旅先でやってみよう

「旅の恥はかき捨て」という言葉があります。
人によっては「旅先で暴れて現地の人に迷惑かけてもいい」
と解釈している困った人もいますが、
私は「旅先で不慣れな風習があるのは当たり前なのだから、間違えても気にしなくていい」
と解釈しています。
気が弱くて普段の行動範囲が狭い人は、これを利用してはどうでしょうか。

たとえば自宅の近所に何かのチェーン店(飲食店など)があるとします。
入ろうと思ったことは何度かあるけれど、
店でのオーダーの方法など、どうやったらいいのかわからなくて二の足を踏んでいる。
かといって人に聞いてまで行くほどのものでもないし...という状態。
一度大きな恥をかいて顔を覚えられてしまうと、
二度と行けなくなるのではないかと心配。

さて、旅行先で同じチェーンの店を見つけたとしましょう。
そこで意を決して入って、恥をかいてしまえばいいのです。
店員に顔を覚えられても大丈夫。次に会うときにはそんなこと忘れています。
二度と会わないかもしれません。

一旦店の利用方法を覚えれば、あとは近所で実践すればいいだけです。
その店は新しい行きつけの店になるかもしれません。
自分のまわりの世界が少しだけ広がります。

旅行にはジャージを持っていこう

旅行をする際の荷物はできるだけ少なくしたい。
特に服はかさばりがち。

そこでジャージの出番です。

部屋着・寝間着になる

ホテルの部屋でゆっくりしたいときは部屋着に着替えたいもの。
そのまま寝間着としても使えます。

そのまま外出できる

格好良いとは言えませんが、
ホテルの近所に買い物に行くくらいならこれで十分でしょう。

防寒着になる

ちょっと肌寒い時はジャージの上着を羽織れば防寒着がわりになります。

ジャージ自体は多少かさばるものの、あれもこれも、と持って行くよりは荷物が減らせます。

ブログ執筆環境を変えたら投稿ペースが 10 倍になった


Blogger でブログを書くようになってから、
ブログの足回りが軽くなったようだ。
投稿数は月1本あるかないか、から週に数本程度まで増えた。
おおよそ 10 倍のペースだ。

当初、Blogger を選んだ理由は、
ブログを運営しているサーバが
建物の設備点検のためやむなく休止したのが発端であった。

そんな日に限って久しぶりに無性にブログが書きたくなったのである。
電力会社による計画停電も近々実施されるかもしれないし、
これが何回もあるのは我慢できない、と思って
代替となる投稿先に選んだのが Blogger だった。

投稿数が 10 倍になったのは
ブログの下書きの閲覧・編集の敷居が下がったことが主な理由である。

私はブログを一気に書き上げることはあまりない。
ネタをよく思いつくタイミング(例:電車での移動中)と
ブログを書きやすいタイミング(例:夜の自宅)がほとんど一致しないからだ。

ネタを思いついたら携帯から Evernote に送るのだが、
最近は Evernote の in-box の整理が滞っている。
そうするとネタは他のノートに埋もれてしまい、
見返すタイミングはほとんどない。
仮に Evernote の in-box の整理ができていたとしても
手元の携帯の Evernote アプリはめちゃくちゃ重いので
下書きを書きためても見返すこともままならない。
そのため、見返す気が起こらなくなった。
ネタはそのままお蔵入りになってしまう。
これまで使っていた tDiary に直接下書きとして書き込むことも可能ではあるが、
ブラウザを介して PC 用画面をちょこちょこと操作する必要があるので面倒で、
これもまた編集する気が起こらない。

しかし、Blogger 、と言わなくてもおそらくほとんどのレンタルブログは
下書きを書きためて管理でき、かつ携帯から簡単に閲覧・投稿することができる。

携帯からの下書きの閲覧・投稿がやりやすくなっただけで敷居はかなり下がった。
ネタを思いついたらその場で携帯の Blogger 専用アプリでメモを放り込めばいい。
そして、PC を広げてブログを書ける環境になってから、
続きをキーボードでサラサラと書けばいい。

おまけに、普段 GMail を使っているせいか
同じ Google が作った Blogger でのブログ作成は
まるで長文メールを書く程度の敷居の低さだ。
月一回、肩の力を入れて書いていたときに比べると非常に楽な気分である。

そういうわけで、ミラーにすぎなかった Blogger だが、
便利さを考えれば、むしろこっちをメインにしようかとさえ考えている。

教訓:ブログが書けないときは、アイデアのメモから投稿までの管理体制を見直してみる

2012年7月1日日曜日

飛行機の乗務員が乗客を非常口座席に座らせようとする理由は?

スカイマークの機内であったことからの寸感。

私はいつも通路側の席に座っている。
トイレに立つときに気兼ねしなくていいからだ。
すぐ近くで夫婦と赤ん坊、そしてその祖父母と思しき五人連れがいて乗務員と相談している。
どうやら彼らの席の間に私が挟まる形になっているのが嫌で、別の席を変わりたいらしい。

すぐ前の席(ただし非常口座席。これが後でポイントになる)が空いているのでそこに座ることになったようだが、離陸時の機体のバランスのためと乗務員が説明し、夫婦と赤ん坊が私の横に座った。
離陸してベルト着用サインが消え、乗務員が夫婦に座席案内をしたら、彼らはもう座席移動しなくてよくなったと返した。

話はこれで終わらない。

しばらくしてまた別の乗務員が来て、今度はなぜか私に座席移動をしきりに薦めてくる。
いやべつに構わないんだけど、という旨を伝えてもまだ薦めてくるので、夫婦の要望が間違って伝達されたのでもない気がする。
若干クレーマー気味な一行に気を遣って、比較的動かしやすい私を動かしたのか?
なんだかよくわからないけど、非常口座席は広いし初めてなので折角だから移動することにした。

さて、非常口座席に座って気が付いた。
どういうことか、非常口座席には私しかいないのである。

ここからは私の勝手な想像である。

え、なにこれ、なんで非常口座席に座らせたいのさ。事故る予定でもあるの?
と、ふざけたことを考えていたら、
ふと、以前TLで、別のLCCで乗務員が二人しかいなかったという話を思い出した。
人件費削減はLCCの課題だろう。
今回乗ったスカイマークの乗務員は四人いたけど、
もし緊急事態が起こった時に乗客全員をサポートするのは大変だろう。

そういう意味ではいざという時のために人手を確保しておくのは乗務員の「ノルマ」なのではないかという推測に至った。

2012年6月30日土曜日

ホーム画面から始める習慣改善

空き時間につい携帯を見てしまう人は、
ホーム画面のアイコンの内容を変えるだけで習慣が変わるかもしれない。

つい見てしまう時は、特に目的がないときなので、
目の前に面白そうなアプリ(SNS)があるとつい見てしまうだろう。

私が Twitter 中毒気味なのを後押ししているのも
ホーム画面に Twitter クライアントがあったからではないかと気づいた。

そこで、Twitter クライアントがあった場所にタスク管理アプリ (Toodledo) を置き、
Twitter 閲覧用のアプリのショートカットは削除してみた。

まだ様子を見る必要はあるけど、
今のところ Toodledo をよく見るようになっている。
無駄に TL を眺める時間が減って、
代わりにタスク管理が回っているような気にはなっている。

携帯に Twitter アプリを 3 つ入れている理由

最近、携帯で Twitter を閲覧するのに複数のアプリを使い分けている。

タイムラインを見るのは SOICHA。
投稿には Seesmic。
通知は Twitter 本家のアプリ。

こうなった理由をひとことで言うと、それぞれのアプリで長所が違うから。

もともとは SOICHA 一本だったのだけど、
どうも通知が遅く、数時間送れるのはざら。
本家はすぐ通知が来るので返信はもっぱら本家のほうを使っている。

昨日から投稿に Seesmic を使うようになった。
この理由は、「閲覧が不便だから」というのがひとつ。

最近 Twitter 中毒気味なのをなんとかしたいと思って
アプリのアイコンを手の届きにくい場所に置いたり工夫したのだけど、
日記や自分用覚書のつもりでツイートしたいときは結局頑張ってそこまで行ってしまう。

考えてみたところ、

SOICHA みたいな良い閲覧環境があると

投稿するついでに普段よく見るリストが目に入るから
閲覧モードに入って横道にそれてしまうのだと気がついた。


とすると、投稿したい時に投稿に集中できる環境を用意すればいい。
投稿しかできないアプリがあるとベスト。
もう少し探せばあるとは思うが、Seesmic は Facebook にも投稿できると知って採用してみた。
ホーム画面のアイコンがひとつ減るのも良い。

2012年6月17日日曜日

DIGNO での写真に関するトラブル

新しい携帯 (DIGNO) にしてから、写真でちょっと困っている。

少なくともデフォルトのカメラアプリを使った時に
カメラ写真の方向認識がアプリによってバラバラなのである。

Blogger 専用アプリでは横長写真のみ思い通りの方向にアップロードされる。
一方で SOICHA で Twitter に投稿すると縦長写真のみ思い通りの方向にアップロードされる。

SOICHA に関してはアプリ内で方向を編集できるので、まあいいことにするが、
Blogger はなんとかならないだろうか。
いちいち PC 側で編集しなくてはならないとすると、敷居が高くて困る。

ちなみに Facebook では専用カメラアプリが立ち上がり、両方とも方向を認識してくれた。

ということはデフォルトのカメラアプリが問題なのだろうか。

もう少し調べることにしますが、
もし何か対処法をご存知の方がいらっしゃれば
教えていただけると幸いです。

GTD における「信頼できるシステム」の難しさ



メールの受信トレイが一杯になる。
机の上が山積みになる。
PC のデスクトップ画面がアイコンで埋まる。

GTD に則って管理システムを構築しているはずなのに、
こうなるのはなぜか?

「週次レビューをやる時間がないから」
というのがもっともらしい答えなのだけど、
この認識は片手落ちだと気づいた。

システムを完全に信用できていないから、
という原因もあるだろう。

たとえば受信トレイからメールを他のフォルダに移すのを
ためらって先送りしてしまうのはなぜだろうか。
それは、他のフォルダに移されたメールを
適切なタイミングで再び見つけられる(思い出せる)自信がないからではないだろうか。

GTD の開祖デビッド・アレンの本の中で、
絶対に忘れてはいけない持ち物を忘れないために「ドアの前に置く」
という話がある。
でもこれは、乱用するとまずいことになる。

忘れるとまずいと思ったものを
安易にドアの前においてばかりいると
ドアの前がいっぱいになり、
本当に必要なものを探すのに時間がかかるし、
ドアの前が通りづらくなる。
これでは GTD 導入前と変わらない。

デビッド・アレンは GTD の説明をする際に
「気になるもの全てを信頼のおけるシステムで管理する」ということを
さらっと言っているのだけど、
信頼できるシステムってそうそう簡単に作れるのだろうか?

私が「信頼できるシステム」の条件は以下のとおり。

1. ポケット一つの原則(全ての情報がそこに入っている、またはそこからたどれる)
2. 検索性の良さ(好きなときに欲しい情報を検索して取り出せる)
3. リマインド機能(必要なときに思い出させてくれる)

1 は比較的簡単に実現できる。Evernote になんでも放り込めばいい。
2 と 3 は、自分の手元では中途半端である。

2 と 3 が実現されていないとなると、
大事そうなもの全てをついつい「ドアの前」
すなわち受信トレイや机の上に置いてしまう心理がはたらく。

週次レビュー(といっても実際には一ヶ月に一回くらいしかできていない)
で片付けはするが、
心の底からは信頼できていないシステムを、
信頼できているものと見なすという葛藤を内心で抱えながら
整理するものだから、
メールを振り分けたりする度にいちいち引っかかっていたように思える。

今すぐ解決策は出なさそうなので、もう少し考えることにする。

2012年6月16日土曜日

生活への投資とその勧誘についての寸感


研究や生活を助けたり、リスクを減らしたりするツールがあったとする。優先度が高く、かつ投資の割に合うならばお金を惜しまず買ったほうがいいとは常々思っている。

たとえば、博士課程に進む学生であれば、低スペックでいいから自分専用のマシンやディスクは持つべきであって、研究室で買ってもらえないのであれば身銭切ってでも持っておくべきだと思っている。過去の経験から、共用の計算機は信頼ならないものだと思っていて、そんなものが止まったくらいで研究が完全に止まる状況なんてあってはならないからだ。

一方で、人に物を買え買えとはとても言えない。

これは多分、一部の Mac 勧誘者たちの話に辟易した経験があるから。今でこそ MacBook Air や iPod touch は持っているけど、当時は私は天邪鬼で、リンゴのマークを見ると顔を背けていた。

必要性を感じていない状態でしつこい勧誘を聞くと、「坊主憎けりゃ袈裟まで憎い」で、購入を勧誘された物品を見ただけでしつこい勧誘を思い出して嫌になるということだ。自分でいいと思ったものが出たら買うのだからそれまで放っておいてくれと。

その記憶が薄らいだころに MBA の 11 インチが発表され、これはこれはと思って買った。このブログも MBA で書いている。

買うべきだと思っているものは、それに近い話題になったとき「買ったほうがいいと思う」くらいは伝えるけど、あまり強い勧誘は逆効果になると思ってやらないでいる。

2012年6月15日金曜日

日付から曜日を暗算できるか?


メールやミーティングログを書いている時に
「この日って何曜日だっけ」と調べることがしばしばある。
いちいち調べることなく暗算できないか。

日付から曜日を計算する公式自体は存在していて、
有名なものに

ツェラーの公式 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%84%E3%82%A7%E3%83%A9%E3%83%BC%E3%81%AE%E5%85%AC%E5%BC%8F

(Wikipedia の式はなんで 26/10 を約分していないのかわからん。)
しかしこの公式を全部覚えるのは大変だし、
いちいち暗算するくらいなら調べたほうが早いだろう。

ここで、暗算できることを優先して考えてみる。
だいたい「あの日は何曜日だっけ」と思う対象は
現在から少し先の未来だろう。
というわけで、特定の月に限定して
大胆な単純化を行ってみると、結果はたとえば

  (日付の日の部分) - 3 mod 7   # 今月(2012/06)の場合

とまで単純化出来る。
ここでは値が 0 のときが日曜日としている。
"-3" というのは 2012/06 であることに由来する数字だ。
これを「今月の数字」と呼ぶことにする
この部分は毎月変わるのでそのたびに覚え直しが必要だが、
ツェラーの公式全体を覚えて計算することに比べれば楽だろう。

来月の場合は、
「今月は何日まであるか」から 28 を引いた数字を
今月の数字に足したものとなる。
今月(6 月)は 30 日までなので来月(7 月)の数字は "-1" になる。

多少の練習は必要だろうが、それなりに実用性はありそうだ。

追記:手元の Google 日本語入力の場合は、「きょう」と入力すると「金曜日」が候補に挙がった。

2012年6月5日火曜日

[debian] debian lenny のアナログ時計


debian lenny にてアナログ時計が欲しくなったのでインストール.

xclock を入れようと思ったらパッケージがない.
etch にはあったのに.

仕方ないので別のを探す.
cairo-clock というのがあったのでそれを入れた.
なかなか見た目がシンプルでよい.
テーマを zen にすると ... 笑ってしまった.


(追記)

  \$ xclock

とやると普通に時計が立ち上がった. 別のパッケージに含まれているようだ.

2012年5月23日水曜日

日食と飛行機のコラボ写真からどこまで分かるか


金環日食の日、日食に飛行機が重なっている写真が話題になっていました。
ちなみにこれは今回のものではなく
2010 年にバンコクで撮影されたものだそうです。元記事は以下。

ニュース - 科学&宇宙 - 今世紀最長の金環食:タイ、バンコク - ナショナルジオグラフィック 公式日本語サイト
http://www.nationalgeographic.co.jp/news/news_article.php?file_id=20100118002

それはさておき、
ふとジョジョの吉良吉影のネタ
を思い出して撮影者から飛行機までの距離を
見積もってみました。
他にも写真一枚から推理できそうなことをメモしておきます。

おことわり:見積もりは桁が合っているかどうかという程度の精度です。

== 撮影者から飛行機までの距離は?

写真によると飛行機の全長の 4 倍が太陽の直径くらいですかね。
よって

  (太陽の半径) : (太陽までの距離) = 4 x (飛行機の全長) : (飛行機までの距離)

太陽の半径は 7 x 10^8 m、
太陽までの距離は 1.5 x 10^11 m であり、
飛行機の全長をざっくり 50 m と仮定すると、
飛行機までの距離は 10 km 程度になります(全長 75 m の仮定だと 15 km)。


== 撮影時刻は?

写真での太陽の欠け具合と、上記サイトに書いてある 2010/1/15 の日食、バンコクで撮影という情報から絞り込めます。
日食時の太陽の情報としては以下のサイトがありました。

日食各地予報
http://eco.mtk.nao.ac.jp/koyomi/koyomix/eclipsex_s.html

2010/1/15 の金環日食を選び、バンコクの緯度経度として
北緯 13° 75′、東経 100° 50′を入力します。

結果を見ると、
写真の太陽の欠け具合に近いのは日本時間の 17:00 頃のようです。

== 飛行機の高度は?

撮影日時と場所が分かれば太陽の仰角が分かります。
さっきのサイトで日本時間 17:00 の高度は 38.2° とのことなので

  10 km x sin(38.2°) ≒ 6 km

ただし、これは先ほどの飛行機の全長の仮定に大きく依存します
(全長 75 m の仮定だと 9 km)。
最初に行った、太陽と飛行機の見た目の大きさの見積もりがいい加減なことを考えると、
上昇・下降中なのか最大高度で巡航しているのかは判断できません。

== シャッターチャンスは何秒間?

ジャンボジェット機が最高速度で飛行しているとすると
おおよそ 300 m/s くらいの速度のはずです。

太陽の見た目が飛行機 4 台分、飛行機の全長が 50 m とすると
太陽一個分を進む時間は 2/3 秒程度。
さらに飛行機が太陽の右下の縁に重なる時間は 1/6 秒ですから
相当タイミングが合わないと撮れない写真だということがわかります。

== その他分かりそうなこと

以下は原理的にはできるはずですが、
データを探すのが面倒なので具体的な値を出していません。

* 写真に写った飛行機はどの便か?
  * バンコクやその周辺の飛行機の航路を洗いだせば絞り込めると思われます。
* 撮影場所をもっと絞り込むには?
  * 撮影場所と飛行機と太陽が一直線に並んでいるので、原理的には飛行機と太陽を結んだ直線と地球の表面が交差する場所が撮影場所のはずです。飛行機の便が絞り込めれば撮影場所の絞り込みもできますが、飛行機の飛んでいる時間と場所をどれだけ精度良く知ることができるかに大きく依存するでしょう。

2012年5月2日水曜日

「切り上げ力」


どうすれば早起きできるかを考えてみる。

早起きする方法は、大きく分けて二つ。
睡眠時間を短縮するか、寝る時間を前倒しするか。
睡眠時間短縮なんて芸当は、
パフォーマンスを保つことを考えると
それなりの訓練やサポートがないと無理じゃないだろうか。
人間の一番強い欲求は睡眠欲だという説があるくらい、眠気に勝つのは難しい。
それよりは、睡眠時間を保ったまま時間を前にシフトするほうが簡単だ。
(活動時間が一緒の長さなら早起きの意味が無い、というツッコミはあるかと思うが、タイムシフトの意味ではそれなりにメリットはあるだろう)

寝る時間を早くするのもそんなに簡単じゃない。
寝るまでのスケジュールが詰まっている日、たとえば
飲みに行った日は帰りが遅いのでそれまでは寝られない。

それ以外では、仕事でもプライベートでも何かしら
「あとちょっと」「もうちょっと」と思って終わる時間を先延ばしにして
遅くなることがそれなりにある。
調子が良い日だと、今のうちにどんどん先に進んでしまいたい。
キリの悪いところにいると、キリの良い場所で終わりたい。
これはスケジュールがうしろにずれたり、
他の予定が犠牲になる原因として結構馬鹿にならない。

そうすると、
早起きするには、
「早起きするぞ!」という信念よりも、
時間が来たら進捗の如何にも関わらず容赦なく切り上げて次に
移れる勇気の方が役に立つのではないか。
勝手に「切り上げ力」と名付けることにする。

家庭に小さな子供がいる人は、切り上げ力が高いイメージがある。
終業時間が来たらバタバタバタっと片付けて速攻でオフィスを飛び出すようなイメージ。
たとえば、子供を幼稚園に迎えに行かなきゃならないなら、
そりゃ仕事が途中であろうがなんでもあろうが放り出して行きたいだろう。

切り上げ力が高い人は仕事が出来るイメージもある。
仕事が出来るから定時で切り上げられるのだ、という反論もあるだろう。
だが、余程切羽詰まっているので無い限りは
容赦無く切り上げるようにする毎日を送れば、
時間内に収めるように考える癖が定着するのではないか、と期待している。

でも、毎日締め切りに追われていたらこの訓練が始められない orz

2012年2月29日水曜日

作業動画の作り方


== 概要

動画投稿サイトへの投稿を念頭に,
PC のデスクトップでの作業風景 (いわゆるデモ動画) を録画する方法を説明する.

== 環境

* OS: Debian GNU/Linux 6.0 (Squeeze)

== ソフトウェアのインストール

 \$ sudo apt-get update
 \$ sudo apt-get install gtk-recordmydesktop   # 録画ツール
 \$ sudo apt-get install mplayer       # 動画プレイヤー
 \$ sudo apt-get install mencoder     # 手元でエンコードする場合は必要

好きなソフトウェアを使いたい場合は適宜読み替えて良い.

=== ディスプレイの設定

この後の作業でスクリーン全体をキャプチャする場合は
負荷を小さくするために解像度を低めにしておいたほうがよい.

Debian squeeze の場合はメニューの
設定 -> デスクトップで解像度を適当な値にする.

== 録画前の準備

=== ウィンドウの配置

録画に必要なアプリケーションを立ち上げ,
好きな場所にウィンドウを配置する.

=== 見やすい動画を作るコツ

* 作業の合間は数秒待つ
* 視聴者がプロンプトやカーソルを見失わないよう, ショートカットなどは使わない
* 注目すべき場所をマウスで指す

== 録画

=== GUI の場合

以下のコマンドを実行する.
これを実行しただけではまだ録画は開始されない.

  \$ gtk-recordMyDesktop

* 音声を録音しない場合
  *「音質」の横のチェックを外す.
* 画面の一部を録画する場合
  * recordMyDesktop の中のデスクトップ画面のサムネイルの中をドラッグして選択する
* 保存される動画名の変更
  * recordMyDesktop の中の「別名で保存」ボタンを選択する

負荷軽減のため「ビデオ質」は 100 のままにするとよい.
おそらく生で出力しているため, 動画のサイズは大きくなるが,
後でエンコードすればよい.

recordMyDesktop 内にある「録音」ボタンを押すか,
画面右上のパネル内の赤丸ボタンを押すかすると録画が始まる.

パネル内の白い四角いボタン (もともと赤丸ボタンだった場所) を押すと録画が終了する.

エンコードのプログレスバーが出てくるのでしばらく待つ.

デフォルトでは out.ogv というファイルができている.

=== CUI の場合

例:

 \$  recordmydesktop --no-sound -o test.ogv --delay 5

上記の場合は, コマンド実行後から 5 秒後に音声なしの録画が始まり,
動画は test.ogv に出力される.
その他のオプションは man の recordmydesktop(1) を参照.

Ctrl-c で録画が終了する.

== 録画された動画の確認方法

適当な動画プレイヤーで開く.

 \$ mplayer out.ogv

== アップロード

適当な動画投稿サイトにアップロードする.

以下のサイトでは, ogv 形式のままで
アップロードできることが確認されている.

* Youtube: http://www.youtube.com/
  * 再エンコード完了までの時間は短め (数分?)
* Vimeo: http://vimeo.com/
  * 再エンコード完了までの時間は長め (数十分?)
  * 他のユーザが元の動画ファイルをダウンロードできる

== ブログなどへの貼り方

=== Vimeo の場合

動画の上でカーソルを動かすと右上に EMBED と表示されるのでそれを選択.
すると貼りつけ用の HTML ソースが表示されるのでそれをコピペすればよい.

== 完成例

((:
GPhys 最初の一歩 from stsnoda on Vimeo.
:))
== (option) 投稿サイトでのエンコード回避

サイトによっては, こちらでアップロードする動画の形式やビットレートなどにより
エンコードされることなくアップロードされる.
詳しくは「再エンコード 回避」などで検索すること.

== (option) 手元でのエンコード

ogv 形式に対応していない投稿サイトでは
自分でエンコードする必要がある.

音声のない ogv から mp4 にエンコードする例:

  \$ mencoder out.ogv -ovc lavc -lavcopts vcodec=mpeg4 -o out.mp4

== 参考文献

* PCの画面をキャプチャした動画をvimeoにアップロードするまでの手順 - seToの日記
  * http://d.hatena.ne.jp/seTo/20100628/1277722476
* [ gtk-recordMyDesktop スクリーンキャスト(動画のデスクトップキャプチャー)] by ひねもすLinux
  * http://linuxos.blog102.fc2.com/blog-entry-26.html
* ubuntu上でogvやaviをmp4に変換する - KRAKENBEAL RECORDS
  * http://krakenbeal.blogspot.com/2010/06/ubuntuogvavimp4.html
* vimeoの貼り方 - 札幌トラックバイク日記
  * http://d.hatena.ne.jp/HOSH/20081208/1228740343

2012年2月8日水曜日

修論発表会心得


過去の自分の見聞や経験をもとにした心得まとめです。
学会発表にも応用できます。

== はじめに

修論発表会を見ていると、発表内容ではなく足回りの不備でこけるケースを見ることがあります。
家に帰るまでも遠足、会場への行き方を調べるのも受験、
ちゃんと発表できる状況に周辺環境を整えておくのも修論発表会です。

このエントリでは足回りの固め方をまとめています。

== PC の不具合を避ける

過去の発表会で、聴衆の目の前で OS 再起動が始まった事態を目にしたことがあります。
人から聞いたのも含めるとこれまでに 3 回知っているのですが、以下の二つに分けられます。

* 自分の発表直前で PC をスタンバイから復帰しようとして失敗した
  * 対策: 自分の前の人の発表が始まった段階で、発表できる状態にしておきましょう。
* 重い動画を再生して OS が落ちた
  * 対策: 直前に資料を差し替えた場合は、最終版資料を再生して問題がないか確認しましょう。
    発表会の朝に OS を再起動して余計なプロセスを削除しておくのもよいでしょう。

最近は昔より OS が安定しているので、いきなり再起動という事態にはなりにくいと想像されます。
しかし、普段よりも PC を酷使しているので不具合は起こりやすくなっているでしょう。
不具合を避けるためにメンテナンスが重要なのは変わりません。

== スライドの投影確認

会場での発表スライドの投影チェックは「必ず」行いましょう。
研究室と会場で同じように映るとは限りません。
色の映り具合によっては、図や字が見えにくくなり、現場での修正が必要になることもあります。
また、全ページ確認しておくのが無難です。

== 発表者交代時のもたつきをなくす

会場でのチェックでもうひとつ重要なのが、発表者の入れ替わり方の把握です。
切替器があるケースでは、切り替える方法を熟知しておきましょう。
もたもたして発表時間が減ったり、座長に注意されたりすると、全力を出せません。

さらに、一見細かいですが、レーザーポインターやマイクの使い方も把握しておきましょう。
発表本番では強い緊張のため、不確定要素への対処力が落ちます。
できるだけ現場に触れて一挙一動をイメージトレーニングしておくと、発表本番がスムーズに行きます。

== 質疑応答 (2012/02/08 後から追記)

質疑応答で、先生の質問が意味不明なことがよくあります。
発表する学生が、制限時間のプレッシャーのためか無理に答えようとして
見当違いのことを言い、先生を苛立たせるケースがあります。
質問が分からないときは「それは○○ということですか?」
と会話したほうがいいでしょう。
普段の研究室の発表なら当たり前ですけど、本番では結構忘れがちです。

先生によっては普段より強い口調で
質問・批判してくるように感じることがあるので驚かないようにしましょう。
わざと圧迫面接っぽくしている人もいるのかもしれませんが、
おそらく、授業している状況しかしらない先生が研究モードになっただけ、
というだけなのが多いと想像します。

== おわりに

私は「修論発表会には魔物がいる」と例えることがありますが、その原因は

* 普段行わないような PC の使い方をする
* 慣れない会場で発表をする

に集約されると思います。
「普段ならやらないミス」をしないためには、
PC を再起動したり、会場で本番さながらの動作確認をしたり、
イメージトレーニングすることによって
環境をできるだけ「普段の状態」に近づけることが、
重要です。

2012年1月28日土曜日

[週次レポート] 1/21-27 のまとめ


== あったこと、やったこと

* 歴史の学び方に関する考えを大量にツイートし、
  こんな歴史の授業を受けたい http://togetter.com/li/244865
  としてまとめた
  * Togetter で作った初めての公開まとめ
  * 機会があればブログにまとめ直したい
  * この中のツイートが自分史上最高の RT 数になった

* LINE 入れてみたが、使わず
  * 自分の電話帳の中の、知り合いの個人情報がサーバに送られる仕様が気に入らない

* Toodledo のお試しプレミアムをする
  * のちに普通のプレミアムに移行

* 堀「理系のためのクラウド知的生産術」を購入した
  * でもまだ読んでない

* 時間ログから一日の「充実度」を適当にでっちあげてみることにした
  * ランキングや新記録が好きなので、ゲーム感覚でやることに。

* 月, 火は午後に集中して作業ができた。それ以降はやや息切れ。

* 作業が進んだ日はそんなに充実感なく、拍子抜けした状態で帰宅する傾向にある?

* Debian Linux (squeeze) で使っている ibus-mozc (野良ビルドした mozc-ut) をやめて、
  squeeze-backports の scim-mozc を使うことにした
  * SCIM は全角、半角にする際に別のキーを割り当てられるため
  * uim のほうはインストール時にエラーになった

* アナログ停波以降、自宅でテレビを見なくなってから半年が経った。

* 大学の図書館の転送サービスを利用してみた

* 最近の Twitter の TL チェックは、知り合い以外のもののチェックはスパースになりつつある

* Echofon から写真付きツイートできることを知って、Twitpic を使わないことにした。

* 適当な気分でつぶやいた「ライフハック川柳コンテスト」がフォロワーさんによって
  ハッシュタグとなって拡散される
  * テンション上がる

* メンテできず、ダラダラしていたプロジェクト (グリッドコンピューティング関係) を畳んだ。


== 先週、やると宣言したことの結果

=== Toodledo のバックアップスクリプトの完成

先週から進んでいません。
Toodledo をプレミアムにしたことにより
バックアップ期間が大幅に伸びたので急ぐ理由がなくなりました。
今は Toodledo よりも Paymo のログを見るほうが
次の行動を練るにあたって重要なので、
このスクリプトに関しては、
また重要だと思うようになるまで休みます。

=== Paymo の時間ログをもとに Toodledo の調整を行う生活を続ける

実行中です。
今日も、今週の Paymo のログを参考に Toodledo のタスクを大幅に変更しました。
Toodledo のタスクリストのぜい肉が削れてきました。

=== 次回の週次レポートから, 時間ログの統計を載せる

計算するプログラムはおおよそできたのですが、
表示をもう少し工夫したいので
掲載は来週からということで。

== 来週やること

* (引き続き) Paymo の時間ログをもとに Toodledo の調整を行う生活を続ける
* 週次レポートに, 時間ログの統計を載せるようにする


2012年1月27日金曜日

タイピングを鍛える以外で 高速に入力するための三つの方法


== はじめに

文字入力が遅いと思考にも悪影響を及ぼします。
頭の中を吐き出すのに時間がかかるとその度に思考が妨げられます。
そして書くのが遅くて億劫だと、
試しに書いて考えてみる、ということをやらなくなってしまうので、
思考もなかなか進みません。

タイピングは練習すれば早くなりますが,
ある程度以上は限界があります
( ((<"タイピング技能検定"|URL:http://web.e-typing.ne.jp/outline/text1.htm>)) によると上級者で 300 字/分程度)。
今回はその限界を伸ばす方法を三つ紹介します。
いずれも多くの OS やアプリに有効であり、一度設定してしまえば済むものです。

== 1. 予測変換機能のついた変換エンジンを導入する

予測変換機能とは、携帯電話での入力のように、
途中まで入力したらシステム側が変換候補を先回りして提示してくれるものです。

私は ((<"Google 日本語入力"|URL:http://www.google.com/intl/ja/ime/>)) を使っています。

Google 日本語入力に限らず, 最近はいろいろな変換エンジンが
予測変換をサポートするようになってきているようです。

=== Windows, Mac の場合

上記ページからダウンロードできるインストーラを使えば入ります。

=== Linux の場合

Google 日本語入力は mozc という名前になります。
Debian Linux (squeeze) でしたら squeeze-backports を apt-line に追記すれば、

  # apt-get install scim-mozc mozc-server mozc-utils-gui

などで利用できます。
ここでは後で述べる理由から、scim-mozc を使っています (SCIM はもはやメンテされてないので微妙な気分ですが)。ibus-mozc, uim-mozc もありますので好みに応じてどうぞ (注意: 記事執筆時点の私の環境では、uim-mozc はインストール時にエラーになるため使えていません)。
また, Emacs 用に emacs-mozc,  emacs-mozc-bin パッケージも提供されています。

SCIM の場合は

  ツールバーの 「システム」 -> 「設定」 -> 「入力メソッド切替器」 -> scim-bridge

を選択したうえで ~/.xprofile に以下を記入します。

  ### scim
  export XMODIFIERS="@im=SCIM"
  export GTK_IM_MODULE="scim-bridge"
  export QT_IM_MODULE="scim-bridge"
  scim-bridge &


この後、ログインしなすと設定が有効になります。

最初は、希望通りの変換候補が現れたときに Tab を押すのに慣れないかもしれませんが、
いったん少ないタイピングで長い候補をザクザクと打てる快感を味わってしまうと
Tab キーの出番がないかと待ち遠しくなると思います。

== 2. 短縮語登録

長くてよく使う言葉、言い回しは
変換エンジンの辞書登録機能を使って、
少ないタイピングで変換してしまうようにします。
具体的にどういうものを登録したらいいのかは
「辞書登録」「単語登録」で検索するとたくさん出てきますが、
基本的には「自分の書く文章によく出てくる単語、言い回し」になります。
例としては以下のようになります。

* 人名
* 住所
* 電話番号
* メールアドレス
* URL
* 挨拶
* 曜日
* プログラムやマークアップ言語の断片

自分が過去に書いたメールを見返すと、
もっとヒントが見つかるかもしれません。
案内文やリマインダはテンプレートを作ってしまうのも手ですね。

私はこういうのも登録しています

* ここから: --------------- ここから ---------------  (「ここまで」も同様)
* ちわく: 地球惑星科学
* けn: 研究室
* みー: ミーティング

おまけ: 一般的ではないですが
((<"地球物理辞書"|URL:http://www.chibutsu.org/jisho/>))
を入れれば地球惑星科学関連の専門用語も登録されます。


== 3. キーマップの変更

少ないタイピングで多くの文字を、という以外にも、
よく使うキーを打ちやすい場所に割り当てる、という方法で
高速化をはかることもできます。

よく言われているのは JIS キーボードでの "CapsLock" と "Ctrl" の入れ替えですね。
こうすると左手小指を少しずらすだけで "Ctrl" に届くようになり、
小指の負担も減ります。

上記に加えて提案ですが、
"半角/全角" も別の場所に移すのをお勧めします。
移動先は、スペースキー横の「変換」「無変換」で、

* 「変換」を押すと全角になる
* 「無変換」を押すと半角になる

というようにします。
Mac では既に「かな」「英数」があるのでそうなっていますね。
こうする利点は以下の二点です。

* 入力が高速になる。
  「半角/全角」を押すのには左手の小指を伸ばす必要があり、
  ホームポジションを戻すためのタイムラグが生じたが、
  新しい位置だと親指のすぐ近くなので一瞬で押せる。しかもホームポジションは崩れない。
* ミスタイプが減る。「半角/全角」でトグルする方式だと、
  現在どっちの状況なのか忘れると半角と全角がひっくり返るので
  F10 キーを押すなどの修正が必要になる。新しい位置だと忘れても
  入力したいモードのキーを押せば必ず期待するモードになる
  (もちろん変換エンジンのアイコンを見ればどっちのモードかは分かりますが、
  いちいち視線移動して確認するよりは上記のように割り当てたほうが速いと思います)。

#余談: 使わなくなった「半角/全角」に "Esc" を割り当てるとさらに便利になるかもしれません。私はまだ試していません。

=== Windows の場合

スバリそのものの記事は見つからないのですが、
((<"Atokで入力ミスを減らす方法(半角/全角|漢字) | Web scratch"|URL:http://efcl.info/2008/0329/res123/>))
が参考になります。
上記は ATOK の場合ですが、MS IME でも似たような設定方法になります。

=== Linux の場合

Debian Linux (squeeze) で scim-mozc を入れた場合は、
「システム」 -> 「設定」 -> 「SCIM 入力メソッドの設定」で設定画面を表示し、
以下の設定をします。

* 「フロントエンド」 -> 「全体設定」の「オプション」で、キーボード配列を「日本語」にする
* 「フロントエンド」 -> 「全体設定」の「ホットキー」に以下を割り当て
  * 「開始」を Henkan (「変換」キー) にする
  * 「終了」を Muhenkan (「無変換」キー) にする
* 「IM エンジン」の「全体設定」の「日本語」で mozc にチェックが入っているか確認

ちなみに ibus-mozc では開始と終了に同じキーしか割り当てられないようなので
あえて scim-mozc を使った次第です。


== まとめ

今回、入力の高速化のために以下の方法を紹介しました。

(1) 予測変換の導入
(2) 短縮語登録
(3) キーマップの変更

最初は慣れないかもしれませんが、
慣れてくると以前より高速かつストレスが少なく入力できるように
なっているはずです。

2012年1月21日土曜日

[週次レポート] 1/14-20 のまとめ


今週も簡単のため箇条書きで。

== あったこと、やったこと

* EGU の発表を申し込んだが, 自分自身が行けるかは微妙.

* 2014 年末までに商業ベースの本を出したいと宣言
  * 練習として 2012 年末にブログを自作の電子書籍にまとめてみる

* 時間ログ Toggl から Paymo に乗り換えた
  * Toggl は一週間で終了したことになる
  * iPhone アプリで、落ちてから再起動したときにタイマーの内容が書き換わるバグを発見、Paymo の中の人に報告するも向こうでは再現せず
  * Paymo の iPhone アプリは上記のようなバグがあるものの, 起動に 10 秒程度かかる Toggl よりもはるかに軽いので使用を継続中.

* 時間ログより以下を発見
  * 通信販売での買い物に時間がかかりすぎてしまう癖を発見. 大まかな流れは以下のとおり
    * 最安値で売っている場所を検索
    * 類似製品が目に入る
    * 目的に対する他のソリューションを思いつく
    * いろいろ探し始める
    * なし崩し的にネットサーフィンに突入
    * 数時間経過
  * 集中できている/できていない時間がわかりやすい
    * 集中できてない時は作業内容を切り替えたりトイレ行ったりと、間隔が短い項目がたくさん並ぶ。Paymo のカレンダー表示だと一目瞭然。
  * 朝型だと思っていたが, どうもスロースターターで夜型らしい
    * 朝はスロースタートで昼食後低迷
    * 夕方以降から日付が変わるくらいまでトップスピードで走る
    * 日付が変わると眠くなって終了
    * 言い換えると, 自分の「習慣化のゴールデンタイム」は夕方以降の身支度以外の時間
      * これまで, 夜は疲れていて新しいことなんて続かないのでは、と思っていたが、実験してみる?

* Sleep cycle alarm clock の状況
  * これまで計測した 74 日間の平均睡眠時間は 5:15
  * ただし, 休日は二度寝することもあるので実際はもう少し長いはず

* ネットサーフィン関連の時間圧縮
  * Twitter の整理
    * Twitter で大量に読み込むと後半が重くなるのでリストを分けてみた
      * もっとよい方法を探し中
  * Summify の見直し
    * ipod でなく PC で見ることにする
    * その矢先, Summify が Twitter に買収され, サービスの先行きが怪しくなったのでやめることを検討中

* スキルの共有に関して、ちょっと考察
  * トリガーとなったのは以下のニュース
    * ((<"脱電子メールの4年間:IBM社員のワークスタイル(WIRED.jp) - Y!ニュース"|URL:http://zasshi.news.yahoo.co.jp/article?a=20120118-00000306-wired-sci>))
  * PC やネットが普及する前は他人の仕事風景がよく見えた (例: 電話応対) ので参考にしやすかった。今は PC 画面を覗き込むのはダメなので、真似ができず格差が生じやすい。SNS で仕事を公開することで以前のようにスキルの共有を促進する環境ができるかも。

* 日曜に研究専用の週次レビューをやることにしてみた

* 佐々木式の方法について気づき
  * ご本人から「PDCA サイクルの A で始まるのに対応」と聞いたが,
    ((<"平本相武「成功するのに目標はいらない!」"|URL:http://www.amazon.co.jp/dp/4769609469>))
    におけるボトムアップ型に対応することに気づく.
  * P (Plan. Goal から生じたもの) で始めるとうまく行く人がトップダウン型
  * 過去の自分の失敗は, ボトムアップ型スケジューリングのくせにあれもこれもと詰め込んでいたせい, と考えた.

* 観測値にばらつきがあるタスク管理の最適化はどうすればいいかと考え中. データマイニングとしてはどうすればいいか, なども.

* えらく淡々と終わった日があった. 拍子抜けしてるが, 良い日だと思われる.
  * 以前は「疲れた」と「成し遂げた」を混同していたので, 疲れきるまで帰らないことも多かったためか

* 自分の時間を自分でハンドルできている感覚を取り戻せてきた.

* 読書管理サービスとしてメディアマーカーを導入
* GMail, Twitter を高速に検索できるサービス CloudMagic を導入してみた
  * あまり使っていない

* iPod に HabiTimer を入れてみた
  * 定期的にリマインドしてくれるアプリ
  * まだ使っていない

* Foursqare のチェックイン数が 500 になった

* Pocket Wi-Fi のファームウェア更新をした
  * 3 回目に成功
  * 充電時間が短くなったり, 使用中の充電が可能になったりしたはず.

* まだまだ, Toodledo で生活を回すための準備に結構時間がかかっている段階
  * そろそろクラウドサービスを集中的にいじるのは控えることにする
  * 趣味の時間を増やす, という目標が本末転倒になっている事態が長く続くと挫折の原因になるので, ぼちぼち進める

== 先週、やると宣言したことの結果

=== Toodledo の過去ログを保存するスクリプトの作成

* 取得およびファイルへの保存はできたが一部不具合がある.
  * データ数が 1000 を越える場合は未対応.
  * 保存された yml では日本語がバイナリ扱いされる
    * 後で確認

=== Toggl (Paymo) による時間ログをもとに, Toodledo のタスクを再編する

* やりました.
* Toggl, Paymo でとった時間ログが 1 週間強たまったので
  Toodledo に反映させてみた
  * タスク数ベースで 4 割が先送りタスクになっていたので
    これを排除. 先週のログに近いタスクリストができた.
  * この週はこのタスクリストで過ごしてみた.
    タスク量が減ったので当たり前だが, 前の週に比べてやり残しははるかに少なくなった.

== 来週やること

* Toodledo のバックアップスクリプトの完成
* Paymo の時間ログをもとに Toodledo の調整を行う生活を続ける
* 次回の週次レポートから, 時間ログの統計を載せる

2012年1月14日土曜日

[週次レポート] 1/7-13 のまとめ


2 回目の週次レポートです。
ちゃんとした文章にしていたら時間がかかりすぎて
長続きしそうにないので、箇条書きでご容赦ください。

== 何があったか

* 1/6 のクラウドタスクセミナーのまとめを帰ってから一気にまとめた
  * ((<"1/7 のブログ"|URL:http://epa.scitec.kobe-u.ac.jp/~noda/diary/?date=20120107#p01>))
  * 「あとでまとめよう」と思っていたら絶対やらない性格なので
  * セミナー講師の佐々木正悟さんと主催の藤本高司さんにお礼とともにブログを書いたことをお知らせ
    * なんと、お二方からブログで引用していただけました。感激!
      * ((<"122 タスクリストとチェックリスト &#8211; ライフハック心理学"|URL:http://www.mindhacks.jp/2012/01/post-4110>))
      * ((<"ありがとうございました!「クラウドタスク管理術セミナー&ライフハックカフェ 」 | 想造ノート"|URL:http://souzou.fuzimoto.info/2012/01/blog-post_07.html>))

* はじめての週次レポートを書いた
  * ((<"1/7 のブログ (その 2)"|URL:http://epa.scitec.kobe-u.ac.jp/~noda/diary/?date=20120107#p02>))

* Toggl で本格的に時間ログを取り始めた
  * 読み込み時間の長さや PC と iPod touch での同期がうまくいかない問題で苦しむ
  * iPod touch のアプリは更新されて少し軽くなった
  * 3 日くらいで多少はログ取りが慣れた
  * 丁度良いタイミングで Paymo を知ったので乗り換え検討中

* 時間ログをとり始めていろいろ気づいた
  * Twitter を見ている時間が多すぎる -> 危機感 -> 整理
    * Twitter のフォロワーとリストの整理
      * 見るリストとタイミングの整理
    * Summify の活用
  * 実測値が精神に与える威力が大きいことに気づく
    * 単なる想像より、心理のはいり込む隙間が小さい
  * トイレや休憩の時間がバカにならない (3 連休期間も含めているが、起きている時間の 2 割)
    * トイレや休憩の時間を見積もりに入れない計画は失敗必至と思う
  * 集中力が切れた瞬間が分かる
    * つい長めに休憩をとってしまった時
    * 作業と休憩が半々くらいになった時

* PC, iPod touch を多少カスタマイズ
  * iPod touch のアプリの画面下側のアプリを入れ替え
    * 左から FastEver snap, FastEver, Toodledo, Toggl
  * ブラウザの初期ページやタブの並びも修正
    * Google Chrome の一番左は Toodledo, その右は Toggl を定位置にした

* RSS, Twitter の特定リストのチェックに堀式速読術を採用
  * 「自分の行動に影響するか?」を頭に入れながら読むようにしている
    * 単に「面白い」だけの話はスキップ
  * Twitter は web で読んでいると重いので対策を考え中

* Toodledo の整理
  * 先週の佐々木さんセミナーの影響から、「タスクリストには実際にやるものだけ表示されているようにする」ということで先月「理想的な生活」として突っ込んだ、「背伸びしすぎた」タスクを Evernote に退避
  * Toggl の結果より、同じ作業でも同じ時間帯にできるとは限らないことがはっきりしたので, 同じ内容のタスクでも
    * 簡単な手順書は Toodledo のタスクに付属するノートに書いていたが、こういう運用するとカイリが生じがちなので Evernote へのリンク的なものを張るようにしようと思っている (方法は気が向いたらブログ化)

* いろんな手順書の作成中
  * しんどい作業は「ペンを持つ」「このコマンドを入力する」レベルまでタスク分解

* 体が冷えていると心身ともに駄目

* Togetter で毎週のツイートをまとめる実験開始

* 睡眠時間の確保につとめる
  * 一部の日は他の日より 1 時間くらい早く寝た


== 先週、やると宣言したことの結果

=== 2012 年の目標とそれをサポートする行動の再構築


やりました。
((<"1/8 のブログ"|URL:http://epa.scitec.kobe-u.ac.jp/~noda/diary/?date=20120108>))
に書いたとおりです。

=== Toodledo の過去ログを保存するスクリプトの作成

できてません。
前に作った、Toodledo の内容を集計するスクリプトにバグが見つかって
バグつぶしをやっていました。
また、あとあとのためにライブラリを整備していたため、ようやく作れる基盤ができた、
という状況です。

#完全に言い訳ですが、デバッグのついでに Toodledo サーバからの session token の取得部分をいじったのですが、
試行錯誤中に 1 時間に 10 回の取得制限に引っかかってストップ、という状況がありました。

== 来週やること

* Toodledo の過去ログを保存するスクリプトの作成
  * 足回りの整備はできたのであとは組むだけのはず

* Toggl (来週から Paymo?) による時間ログをもとに, Toodledo のタスクを再編する
  * 実績を叩き台にして、理想に近づくよう改変していく作戦をとる
  * とりあえずは、土日中に時間ログ (実績) を Toodledo に反映し、平日はその実績を上回るようなパフォーマンスを出せないか考えながら行動する
    * でも来週は不定期なイベントが入っているので先週をなぞるようにはやれないだろう

2012年1月9日月曜日

[toodledo] Toodledo で深夜のタスクに生じる問題と、その部分的解決策


== はじめに

佐々木正悟さんの「((:<a href="http://www.amazon.co.jp/dp/4492580948/">クラウド時代のタスク管理の技術</a>:))」に倣って、
生活に関する全ての行動をタスクとして Toodledo に突っ込んでみたところ、
深夜にちょっと困ったことが起こりました。

== 問題点

私は 24 時に寝るのを目標にタスクを登録しているのですが、
時としてそれ以降にずれ込んでしまうことがあります。
そのときは、日付が変わってからタスクにチェックを入れることになるのですが、
タスクの繰り返し条件を "Repeat from Completion Date" としているものがあると面倒なことになるのです。

具体例を挙げましょう。
毎日 23:50 に終了予定の繰り返しタスクがあったとします。
たとえば今日が 1/9 とすると、1/9 の 23:50 が終了予定です。
このタスクがなんらかの都合で遅れて 1/10 の 0:10 に終了したとしましょう。
言い換えると、1/10 の 0:10 にチェックを入れることになります。
もし、このタスクの繰り返し条件が "Repeat from ((*Due*)) Date" ならば
次は 1/10 の 23:50 に終了予定がセットされます。
これは期待した動作です。

では、このタスクの繰り返し条件が "Repeat from ((*Completion*)) Date"
ならばどうなるでしょうか?
チェックを入れたのが 1/10 になってからですから
1/10 の分が終わった扱いになってしまい、
次は 1/11 の 23:50 に終了予定がセットされるのです。
つまり、1/9 の分をチェックしたつもりが 1/10 の分まで消えてしまうのです。
これは期待した動作ではありません。

このまま使う場合は、
チェックを入れる際には時計を見て、日付が変わっていた場合はチェックしてから
Due Date と Start Date を一日戻す、という操作をしなくてはなりません。
別の方法としては、 "Repeat from Due Date" にしておけば
タスクがスキップされるのは避けられますが、
それだと「このタスクは本当は "Repeat from Completion Date" である」
と覚えるかメモする必要がある上、
チェックを入れたあとに Due Date と Start Date
が期待した日になっているか確認・調整する作業をしなくてはなりません。
どちらの方法も面倒くさいので困っていました。

== 部分的解決策 (ブラウザ版)

先日、根本的ではないものの解決策を思いつきました。
それは

「タイムゾーンの変更」

です。
先に、欠点を挙げておきますと

* アラームなど時刻に関係するものを使っている人にはおすすめできない
* ブラウザ版には有効だが、iOS などのクライアントには現実的ではない

となります。

佐々木式に Context でセクション分けをしているだけなら問題は生じないと思われます。
また、私の手元では今のところ、タイムゾーンの変更前後で
Start Time, Due Time に入力した日時がずれるなどの
症状は起こっていません。

ブラウザからのタイムゾーンの変更方法は以下のとおりです。

((*注意: タイムゾーンの変更により何らかの悪影響が生じる可能性があります。自己責任で行ってください!*))

  画面右上の Setings
  -> Account Settings の中の Timezone Regional Settings の欄の右側にある edit を選択
  -> Timezone の欄の auto のチェックボックスにチェックが入っていたら外す
  -> auto のすぐ左のプルダウンを選択して好きな時間だけ巻き戻す
  -> 下にある黄色い Save Changes ボタンを選択

日付が変わった後にこの操作をやって
Hotlist などをリロードすると、表示が前の日に戻るのが分かると思います。

巻き戻す時間数ですが、
確実に寝ているだろう時刻と 0 時との差だけ巻き戻せばよいと思います。
私の場合は AM 5 時には確実に寝ていると思い、5 時間巻き戻しました。
こうすると、Toodledo の中では日本時間の AM 5 時になってから次の日になるので、
その時刻までなら "Repeat from Completion Date" のタスクにチェックを入れても先程の問題は生じなくなりました。
これで、深夜のタスクに関する問題は解決しました (ただしブラウザ版に限る)。


== 部分的解決策 (iOS 版クライアントの場合)

ブラウザ以外からも操作している場合はもう少し設定が必要です。
私は iOS 版クライアントも使っていますが、
そのままの設定で同期するとブラウザ版のタイムゾーンが元に戻ってしまいました。

iOS 版クライアントでは以下の設定をする必要がありました。

  アプリを立ち上げる
  -> 右下の「設定」タブをタップ
  -> 「一般設定」の「同期」バーをタップ
  -> 「タイムゾーンの同期」をオフにする

これで同期してもタイムゾーンが変わらなくなりました。
ただ、iOS 版クライアントのほうでは iOS のタイムゾーンを使うようで、
本気でやるなら iOS の「設定」でタイムゾーンをいじらなくてはいけません。
さすがにそれは他のアプリへの影響が大きすぎるのでやりませんでした。

== さいごに

結局、「日付が変わった場合はブラウザから操作する」という条件がついてしまうのですが、
従来よりは考えることや操作数が減ったのでまあいいか、と考えています。

根本的な解決方法をご存知でしたらぜひ教えて下さい。

2012年1月8日日曜日

2012 年の目標・生活習慣 (改訂版)


((<"2012 年の目標・生活習慣"|URL:http://epa.scitec.kobe-u.ac.jp/~noda/diary/?date=20120106#p01>))
を改訂しました。
最初のものに、1/6 に参加したセミナーで学んだ内容を取り入れたものです。


== 当初の目的の再確認


* 「趣味など自発的なタスクをもっと楽しむ (やる)」のが原点!
* -> 自発的なタスクにとりかかる時間を増やす
* -> 自発的でないタスクにとりかかる時間を減らす
* -> タスク処理効率化
* -> タスク管理ツールの導入、過去の成功パターンを使いまわすための時間ログ取り




== 2012 年の目標


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


これは変わらず。
「自発的タスク」の定義は
((<"1/6"|URL:http://epa.scitec.kobe-u.ac.jp/~noda/diary/?date=20120106#p01>))
と同じなので省略。


== 目標達成のために習慣化すること


* Toodledo を中心に生活を回す
* 時間ログとり。「ログ=タスク」化 (Toggl <-> Toodledo)
* 「やること」だけを Toodledo に並べるようにする (someday 管理) (Toodledo <-> Evernote)
  * Toodledo から GTD における "someday" を追い出す
* (あれ? プロジェクト管理は?)




== 具体的行動


大筋では大橋・佐々木式を採用。
ただし現時点では TaskChute は使っていない。


=== 最初の一回だけやること (習慣化サポートのための下準備)


* 毎週自分に「週次レポート」を書くようにリマインドさせる
  * 自分宛にリマインドメールが届くようにする
  * Toodledo で週次タスクとして登録
* 各種プログラムの作成
  * 詳細は後述の「毎日やること」「毎週やること」内の「自動で実行されるようにすること」を参照
* Evernote の掃除
  * someday に対応する領域が乱立していたので統廃合
    * 量が多いので一日少しずつやるよう繰り返しタスクとして Toodledo に登録
* Toodledo での繰り返しタスクの名前を Toggl に PC で入力しておく
  * Toodledo と共通のタスク名を使いたいが、長いタスク名をフリック入力するのはストレスになるので
    * 過去に入力したことのあるタスクは入力支援がある (いつまで有効?)
  * 1 秒くらいのダミータスクとする


* Toodledo のカラムの並び順を変更
  * Due Date がタスク名の近くにあると、"Today" より古いものを書き直し (先送りし) たくなる癖が出てしまうため、Due Date, Start Date を右端に追いやる


=== 常に心がける




* 時間ログ取りの習慣化
  * Toggl での時間ログ取り


* (これまでやってしまっていた) Toodledo 内で日付の先送りはやらない


  * 週次レビューのときに、一週間以上先送りしたタスクをリストラしやすくするため


* Toodledo での view の工夫
  * 今やるものだけ目の前に並んでいるようにする。 Star つけたものだけ表示させるとか


=== 毎日やること


+ 自動で実行されるようにすること




* 「日次レポート」の自動生成
  * 前の日の「自発的タスク」「全タスク」のログ (合計時間) をとる


* Toodledo 内の全ログを取得してバックアップ
  * Toodledo は無料ユーザだと一週間で完了タスクが消えるので、消える前に手元にためておく
  * あとから別の解析できるように


* Toggl 内の全ログを取得してバックアップ
  * (Toggl の保管期限はいつまで?)
  * あとから別の解析できるように


#* Toodledo に今日あるタスクで Toggl に 1 週間以内にないタスクは、Toggl に名前を自動登録する
#  * iOS でいちいち入力しなくていいように
#    * 両サービスで名前を一致させる (解析するときも楽)
#  * 経過時間 0 秒のタスクは作れるか?


+ 日次レビュー


* Toodledo のメンテナンス
  * 睡眠時間も含め、1 日の行動時間が 23 時間程度に収まるようにする
  * 通常、1 週間先まで調整する


=== 毎週 (土曜日) やること


+ 自動で実行されるようにすること




* 「週次レポート」の自動生成、自分へメール
  * その週の「自発的タスク」「全タスク」のログ (合計時間)
  * Toodledo の当初予定と、Toggl のログを比較できるように並べる
   * 単純に Excel 的に表にする (TaskChute を参考に)
   * (option) (Google) Calendar 上に並べる


  * その他適当に。option でカレンダー形式に並べたり棒・円グラフにしたり


    * タスク別平均経過時間
    * 時間帯別効率
    * 先送りしたタスク一覧


* Toggl と Toodledo でタスク名が一致しているか確認
* 同じタスクに対して Toggl のプロジェクト名と Toodledo のフォルダ名が一致しているか確認






+ 週次レビュー (の一部)


* Toodledo のメンテナンス
  * 先送りされているタスクの除去
    * Due Date が一週間以上古いタスクを絞り込み検索し、やらなくても問題が起こらないものは Evernote の someday ノートブックに戻す
    * やらないと問題が起こるものの対応は後述
  * タスクのうち「自発的タスク」だと思えるのに "free-will" タグがついてないタスクはないか確認


    * "free-will" タグがついていないもの、かつ Due Date が一週間以内のものを絞り込み検索する
  * Evernote の someday 領域を見て、やりたいタスクがあったら Toodledo に移動させる


* 「週次レポート」の確認
  * 「週次レポート」をブログで公開する
    * 人の目による強制力を利用
    * タスクが詰まった時期でも続けやすいよう、概要+簡単な感想のみ
  * 目標を微修正する


    * 丁度良い難易度になるように
  * 各タスクの作業内容の見直し
    * 予定と時間ログの結果が大きく乖離している場合
      * Toodledo での見積もり時間の修正
      * 予定より時間がかかりすぎの場合
        * 作業手順 (書) やチェックリストの作成、見直し
          * それをやるタスクを Toodledo に入れる
    * 先送りしてしまったが、リストラできないタスクの場合
      * ハードルを下げる


        * タスクを分解できるか?
        * Toodledo の該当タスクのノートには手順書やリストへのリンクがあり、アクセスしやすくなっているか?
        * 手順書に抽象的な記述はないか?
        * 準備の際にアクセスが困難なことはないか?
        * 楽しくないがやらなきゃいけない作業は、どうすれば楽しくできるか? (2012/01/09 追記)

    * 成功した/先送りしてしまったパターンはあるか?


      * 成功パターンは使い回す
        * Toodledo への設定反映. 繰り返しタスクならそのまま維持
      * 予定通りタスクを進めやすい時間帯はあるか? (「習慣化のゴールデンタイム」)
        * 習慣化したいタスクがあればそこに配置してみる
      * 失敗パターンは避ける
        * 再スケジューリングする

2012年1月7日土曜日

[週次レポート] 1/1-6 のまとめ


予め宣言した通り、今年の目標に関する週次レポートを書きます。

今週は週末から開始したのでたいしたことはやってないのですが、
1/6 (金) のセミナーに参加して良い影響を受けてきました。
なのでいきなり目標に関して再構築をやります (笑)。
やったことと来週やることは以下の通りです。

== やったこと

* 目標を立てた
* セミナーに参加した

== 来週やること

* 2012 年の目標とそれをサポートする行動の再構築
* Toodledo の過去ログを保存するスクリプトの作成
  * ライフログの自動取得および、別途作るかもしれないツールの一部として

2012/01/06 クラウドタスクセミナーのメモ


2012/01/06(金) に
((<"クラウド時代のタスク管理の技術&「習慣化」を考えるワーク"|URL:http://kokucheese.com/event/index/24066/>))
(場所: 西中島南方 (大阪府)) に参加してきました。
ライフハック系のセミナーへの参加は初めてでしたので、
どういう雰囲気か分からず緊張していました。
部屋に入ってみたら、数十人規模の研究会と似たスタイルでしたので安心しました。
受付で会費を払って、適当な席に座って、前説明を聞いてレクチャーを聞いて、という流れです。

大いに違った点は、司会や講師の話のうまさ。さすがです。
最後のワークや、参加者の多様さ (色鉛筆でノートを取る方がいらしたり)
も印象深いです。

以下、第一部の佐々木正悟さんによるレクチャーの中で
「おお!」と思った部分のメモの要約です。
若干文章が荒いですが、勢いを失わないうちに。

== 1. 基本的に「タスク管理ツール (Toodledo) さえ見ればいい」という状態にすべき

タスク管理ツールを見て、他のツールを「見に行って」、タスク管理ツールに帰ってくる。
カレンダーやプロジェクト管理ツールの内容を Toodledo に「落とす」「移す」ではない!
(毎日) 見に行け! 見に行かなくなったら先送りの始まり。

見に行く障壁を下げるために、
各ツールでの「フォルダ名の完全一致」 (クラウドタスク本 p.138 に書いてある) は地味でも重要。
こうしておけば、どこを見に行けばいいか一目瞭然なので。


== 2. 習慣化のゴールデンタイム (という言葉は現場では使われてなかったが) を把握する

まず 7 日間、作業のログをとってみる。
先送りした・できなかったこともログに記す。
どういう条件だと成功・失敗するかを知るため。

もし、割り込みや先送りが生じることなく
毎日同じタスクを繰り返せている時間帯があれば、そこはとても重要。
その時間帯に習慣化したいタスクを詰め込むと継続しやすい。
あるいはプロジェクトを細切れにして少しずつ回すようにする。


== 3. ログ=タスクのシステムを作る

タスクシュートの基本思想: 「パターンから未来を予測できるはず!」

「成功したパターンは未来に転記する」 => PDCA サイクルの、記録が先のバージョン

「こうやればこうなった」のログをもとにタスクや目標を組み立てると、
過去にやった実績に基づいているので、やる気も出やすい。


== 4. 同じ「アクションモード」(= 作業の種類) の作業はまとめた方が動きやすい

アクションのチェンジ回数を少なくする。
佐々木氏の場合、「アナログ作業」「Mac 操作」「iPhone 操作」などに作業を分類。


== 5. タスク管理ツールには「やること」だけが書いてあるべき

GTD の someday (いつかやる/たぶんやる) はタスク管理ツールで扱うべきではない。
何度も先送りされるタスクは原則締めだすべき。

一週間放置・先送りされたタスクは捨てるか、Evernote の「カタログ」ノートブックに追い出す。
一週間に一回、週次レビューで中を見て、やることだけ Toodledo に引きずり出す。

2012年1月6日金曜日

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 月中
  * 計測結果をみて目標を微修正する

以上。