時間の流れがゆっくり感じられるためにすべきこと

年をとると時間が経つのが速く感じられるという。色々な心裡的説明がなされ
ているが、いま一つ私も説明を試みてみたい。

学校に通っていた頃は何事も学年に結びつけて覚えている。たとえば、三年に
一回開かれる学芸会が開かれるとして、前の学芸会のことを「二年生のときに
あった学芸会」と記憶している。だから、五年生のときに学芸会がある年が回っ
てきて、「もう三年も経ってしまったのか」とは思わない。

一方、二年に一回の車検があるとする。前の車検のことを、「○○年にあった
車検」と記憶している人はほとんどおらず、たんに「前の車検」ということで
記憶の隅にしまってある。そして、二年経って新たに車検の時期が来たときに
なってはじめて、タイムスタンプのない過去の車検の記憶が呼び出される。タ
イムスタンプがないから、それがいつの記憶だったのか、実感としてわからな
い。この実感のなさが「もう車検の時期か」という気持ちになる。

なにも○○年の車検というふうに年号と結びついていなくても、「沖縄に旅行
した年の車検」とか「長男が小学校に上がった年の車検」とかいうふうに他の
記憶とリンクした形で記憶していれば、それでタイムスタンプの役目を十分果
たす。ところが、年をとると、どういう形にせよタイムスタンプのない記憶が
増えていく。仮にタイムスタンプが押されているものであっても、「○○氏が
首相をしていたとき」などと、その精度が低くなっていく。

タイムスタンプのない記憶が増え、また、互いに時間的なリンクを持たない記
憶が増えていくにつれて、われわれが任意の記憶を呼び起こしたときに感じら
れる、そのイベントからの経過時間が実感できなくなる。

もしこの説明が正しいとすると、時間の流れをゆっくり感じるようになるため
にするべきことは、はっきりしている。つまり、イベント間の時間関係を正確
に把握すればよいのである。

Kindle 3 で電子石碑を作ってみた

Kindle では自然と英語を読むことが多くなる。
英語を読むと疲れるので、目を休めるために見るものがほしくなる。

そこで、拓本の画像を入れて、電子石碑？を作成してみた。
拓本を見るのに、Kindle はなかなか良い端末だと思う。



1. 拓本の原データを http://www.yingbishufa.com/ldbt/index.htm から拝借
一つの石碑がたくさんの jpeg 画像に分かれている

2. for N in `seq -w 1 48`; do convert ${N}.jpg ${N}.pdf
などとしてそれぞれをいったん pdf に

3. pdftk *pdf cat output.pdf
などとして、一つの pdf にまとめる

4. calibre を起動して、mobi 形式に変換
このときメタ情報を編集

5. Kindole 3 をマウントして、 documents フォルダに投げ込む

jpeg を入れたフォルダを zip -r out.zip ./mydir
などとしても、Kindle はこれを読んでくれるが、
一つの pdf にまとめておいたほうがきれいに表示される。
さらに、作者名などのメタ情報を入れるために、ここでは mobi にしてみた。
mobi だと画像の拡大も容易である。

やる気の出ない日

中学・高校の頃、どうも勉強に対してやる気が出ないということを悩んだものだ。大人になっても、やっぱりやる気というものが出ない日もある。というか、そういう日のほうが普通だったりする。

そういえば、むかしよく「やっているうちにやる気が出る」などと言われたものだ。それは本当なのかな、と今思う。

どうも「着手するからやる気が出る」というより、「着手してみないと、やる気があるかどうかわからない」という面があるようである。

つまり、やる気になっている時間をいかに有効に使うかという工夫が必要だと思うのだ。そのために、着手してやる気を調べる。これが自分にとってはしっくりいく考え方である。

python + tweepy + OAuth 最低限度の twitter メモ(3)タイムライン

http://joshthecoder.github.com/tweepy/docs/api.html# を見ながら、
tweepy でホームタイムラインを得てみようと思う。

まず、以下は念仏のように最初にやって api オブジェクトを得ておく。

--------------------------------------------------
#!/usr/bin/env python

import tweepy
import type

CONSUMER_KEY = ''
CONSUMER_SECRET = ''
ACCESS_KEY = ''
ACCESS_SECRET = ''

auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
auth.set_access_token(ACCESS_KEY, ACCESS_SECRET)
api = tweepy.API(auth)
------------------------------------------------------

このあとに
api.home_timeline()
とやると、最新２０個の投稿のリストが得られる。

このリストの要素はそれぞれ
<class 'tweepy.models.Status'>
のインスタンスである。
これには、以下のような変数が入っている。

api <class 'tweepy.api.API'>
contributors <type 'NoneType'>
truncated <type 'bool'>
text <type 'unicode'>
created_at <type 'datetime.datetime'>
author <class 'tweepy.models.User'>
in_reply_to_status_id <type 'NoneType'>
coordinates <type 'NoneType'>
source_url <type 'str'>
source <type 'str'>
favorited <type 'bool'>
in_reply_to_screen_name <type 'NoneType'>
in_reply_to_user_id <type 'NoneType'>
place <type 'NoneType'>
geo <type 'NoneType'>
id <type 'long'>
user <class 'tweepy.models.User'>

（ドキュメントが見つからないから__dict__ を調べた）

テキストの内容は、text <type 'unicode'> だから、
最新（０番目）の投稿本文は、
api.home_timeline()[0].text
で得られる。

また、この投稿者名は、author で、<class 'tweepy.models.User'>
のインスタンスである。
そこで、これが持つ変数を調べてみると、

profile_use_background_image <type 'bool'>
id <type 'int'>
api <class 'tweepy.api.API'>
verified <type 'bool'>
profile_sidebar_fill_color <type 'str'>
profile_text_color <type 'str'>
followers_count <type 'int'>
profile_sidebar_border_color <type 'str'>
location <type 'str'>
profile_background_color <type 'str'>
utc_offset <type 'int'>
statuses_count <type 'int'>
description <type 'unicode'>
friends_count <type 'int'>
profile_link_color <type 'str'>
profile_image_url <type 'str'>
notifications <type 'bool'>
geo_enabled <type 'bool'>
profile_background_image_url <type 'str'>
screen_name <type 'str'>
lang <type 'str'>
profile_background_tile <type 'bool'>
favourites_count <type 'int'>
name <type 'unicode'>
url <type 'str'>
created_at <type 'datetime.datetime'>
contributors_enabled <type 'bool'>
time_zone <type 'str'>
protected <type 'bool'>
following <type 'bool'>

したがって、最新（０番目）の投稿について、
api.home_timeline()[0].author.name で名前
api.home_timeline()[0].author.screen_name でスクリーンネーム（@の後につけるやつ）を知ることができる。

まあ、タイムラインを一通り読めるようになった。

つぎは、最新２０より前の投稿を得ることを考えてみよっと。（つづく）

python + tweepy + OAuth 最低限度の twitter メモ(2) 投稿

twitter の話。
Python + tweepy で OAuth を使って認証して、まずは投稿を試みむ。

昨日までに、
CONSUMER KEY, CONSUMER SECRET, ACCESS_KEY, ACCESS_SECRET の四つを
手に入れたので、あとは、これらを使って tweepy で投稿する。これは、簡単

http://jmillerinc.com/2010/05/31/twitter-from-the-command-line-in-python-using-oauth/

の、Step 4: Create the command line script に、第一引数として渡された文字列を投稿するスクリプトが載っている。使い方は、Step 5: Send a test tweet from the command line に。

次は、タイムラインを読む。（つづく）

python + tweepy + OAuth 最低限度の twitter 開始メモ

そろそろ twitter は AOuth 認証しかダメになる。今更だけど、Python で最低限度の作業をすることにしたので、先達に感謝しつつ、メモしとこ。

python で tweepy を使うのが安易そう。

OAuth の仕組みについては、http://tools.ietf.org/html/rfc5849
でいいのかな。細かいところまで見なくても、なんとかなりそう。

twitter にアプリを登録して、twitter の自分のアカウントにそのアプリからのアクセスを許可するまでの手順は、

http://jmillerinc.com/2010/05/31/twitter-from-the-command-line-in-python-using-oauth/

にかなり親切に書いてあったのでそのまま真似た。thank you

あとは以上で手に入れた CONSUMER KEY　と　CONSUMER SECRET と ACCESS KEY　と　ACCESS SECRETを使って作業すればよい。

http://joshthecoder.github.com/tweepy/docs/index.html
に tweepy のドキュメントがあったぞ。だが、不完全だな。

（つづく）

当確に必要な票数の計算（小学生向き）

小学生に、当確まであと何票必要かの計算を説明てみる。

図は、２５人のクラスで２人の委員を選ぶ選挙の場合。
現在のところ、１８票が開票されて、あと７票の行方が注目されるとする。

Ｂさんが当確になるためには、あと何票必要か、という問題。



Ｂさんの敵陣営の気持ちになってみるとわかりやすい。
彼らは全力をあげてＢさんを落選させようとしている。
彼らにとっては、Ｂさん以外なら誰でもいいのである。

「とにかく、ＡとＣに票を集中させるんだ」

と彼らは言うだろう（便宜的に、未開票ぶんを、まだ投票されていないと考える）。現在のところ、彼らの陣営で一番見込みのある二人がＡとＣだからだ。

Ｂさんとしては、彼らのこの戦略にギリギリで勝てるラインを確保すればよい。

この戦いがＢさんにとっても反Ｂさんにとっても、ギリギリで進行していくとすると、未開票は、Ａ、Ｂ、Ｃの各氏の得票を揃えるように積まれていくはずである。

そして、最後の一票。これをＢさんがいただけば、Ｂさんは当選できる。これが一番Ｂさんにとっていちばんギリギリの勝利パターンだ。敵陣営にとっては、Ｂさんにそれだけの票をとらえたら、残りの票をどう動かしてもＢさんを落選させることはできない。

そして、Ｂさんは、それだけの票に一票とどかないと、確実に勝利できるとは言えなくなる（同数票で決戦投票になる場合は当確とは言わないだろう）。

最後に２票以上残っている場合とか、最初から当確の候補者がいる場合とか、バリエーションはあるが、考えてみればすぐわかる。

（やっつけメモ）その場しのぎの id3 タグ文字コード変換

「パブリックドメイン・クラシック」http://public-domain-archive.com/classic/ というページから mp3 をいただきて Rythmbox で聴きたい。そのために id3v2 タグを utf-8 に変換した。

もちろん、いいかげんにシェルスクリプトで済ます。(bash用)
その場しのぎ度120%

filename=$1
# artist
id3v2 -2 --artist="$(id3v2 -l ${filename} |nkf -w | sed -n '/^TPE1/p' | cut -c 38-)" ${filename}
# title(song)
id3v2 -2 --song="$(id3v2 -l ${filename} |nkf -w | sed -n '/^TIT2/p' | cut -c 44-)" ${filename}
# album
id3v2 -2 --album="$(id3v2 -l ${filename} |nkf -w | sed -n '/^TALB/p' | cut -c 32-)" ${filename}
# year
id3v2 -2 --year="$(id3v2 -l ${filename} |nkf -w | sed -n '/^TYER/p' | cut -c 14-)" ${filename}
# genre 32:classical
id3v2 -2 --genre=32 ${filename}


引数に xxx.mp3 を与える。

ヘラクレスのイメージ

ヘラクレスというと、ムキムキの青年で、どちらかというと男前というイメージだった。たとえばディズニーのヘラクレスが、いくらかそれに近い。

今日、「大ローマ展」なるものを見に行ったところ、紀元前後にヘラクレスを描いたフレスコ画をいくつか見ることができた。ところが、描かれている彼は、肉のたるんだ（きっとプロレスラーの如くその下に隆々たる筋肉があるのであろうが）にやけたオヤジなのである。

そのうち一枚は、女王（オンパレー？）の奴隷（かつ愛人）になっていたときのものであり、彼のトレードマークである棍棒はその女王のほうが持ち、彼は女の服を着ているのだ。

どうも、イメージと違う。そこで、手近にあった参考書（呉茂一「ギリシア神話」新潮社）を見てみることにした。同書（一巻本のやつ p.340）によると「彼はしばしば大失敗をやる、下卑た所業にふける。彼はアテーナイの喜劇が、喜んでいつも持ち出す人物の一人であった。食しんぼうで色好みで、助平な、自分の力を持てあます男」なのである。

つまり、どうも今日見たフレスコ画のほうが正しくて、私が今まで持っていたヘラクレスのイメージが間違っていたらしい。（ギリシャでも、やっぱり同様の事情なのではないかと想像する。）

この発見の感動？を伝えようと、ヘラクレスの画像を検索してみた。ところが、どれもこれも体脂肪率が10パーセントを切っているような絵ばかりで、あの緩んだ感じを伝える画像が見つからない。はあぁ、私がヘラクレスを勘違いしたのも、故無きことではなかったのだと気づいた。

たしかに今日見たローマのフレスコは、美術的には周辺的なのかもしれない。しかし、教えられるところは大きかったように思うのである。

リスニング

いつまで経ってもリスニングが満足にできぬ。たいして訓練していないじゃないかと言われればそれまでだが……って、いやいや、それなりに努力はしたんだ。

で、今仮説を立てた。

ネイティブって、ちゃんと発音なんかしていないよね。
発音してないものを聴きとろうとするからいけないんじゃないか。

なんで発音してないものが聴き取れるのかというと、そう聴くしか選択肢がない場合は、そう聴こえるという脳内のトリックではなかろうか。一種の空耳。

日本語でもそうだ。ドラマで、
「オンドゥルルラギッタンディスカー!?」
なんて言ってるのに、視聴者にはちゃんと意味がわかる。

この場面を日本語のわからない外国人に聴かせて、辞書を引いて意味を調べろとか言ったら、まあわからないだろう。

「本当に～ですか!?」「裏切った」
という表現を知っているから、「本当に裏切ったんですか1?」に聞こえるのだろう。

つまり、英語のリスニングも、表現を覚えて空耳すればいいのではないか。
ようするに、暗記である。

というのは、あくまでも仮説で、今年はこの仮説に基いて練習してみるつもりなのだ。リスニングが向上しなかったら、仮説が正しくなかったってことで。