hatena
<body>
*1240722718*「いつかやる」リストの整理
GTDの本質は「みえる化」と「みえない化」だと気づいたので、TODOリストの「いつかやる」リストを「みえない化」した。
>||
いつかやる: (やりたい順)
- (以下３ページほど続く)
||<
を
>||
いつかやる: (やりたい順)
- 続きは [[いつかやる]] やらなくてもいい
||<
に書き換えて全部「いつかやる」ページに移動した。いつかやるリストが溜まってきたら適当に「いつかやる」ページに移動する。保存はされているのでいつでも見返すことはできる。そして普段は目につかない。めでたしめでたし。
*1240732191*「ひらがなのしりとり圏」 in Python
<a href='http://d.hatena.ne.jp/m-hiyama/20090424/1240552575'>完全実装付きでもう一度お送りします、しりとりの圏 - 檜山正幸のキマイラ飼育記</a>のJavaScriptによるしりとりの圏の実装をPythonに移植しながら読んだ。圏論がわかった気がする！
僕の理解が正しければ
- <del>「対象aに対する恒等射」は一つとは限らない
-- 対象「あ」に対する恒等射が「あああ」でもよい</del>
-- わかった、id(x)がcomposeに対して単位元になるという条件から「あ」じゃないといけないんだな。firstとlastに関してだけ考えていた。
僕は文字と文字列の区別がないPythonでやってしまったので誤解を招くかもしれない。ObjectクラスとMorphismクラスを作って別物であることを明確にした方がいいかもしれない
理解できた気がするので、これを見ないでもう一度0から実装する。
>|python|
# -*- encoding: utf-8 -*-
"""
「ひらがなのしりとり圏」 in Python
http://d.hatena.ne.jp/m-hiyama/20090424/1240552575
のPythonへの移植
"""
def _force_unicode(s):
if isinstance(s, str):
s = unicode(s, "utf-8")
return s
def _print(s):
if isinstance(s, unicode):
s = s.encode("utf-8")
print s
def _is_hiragana(x):
"""ひらがな1文字かどうかを返すユーティリティ関数
>>> _is_hiragana('あ')
True
>>> _is_hiragana('あうー')
False
>>> _is_hiragana('x')
False
"""
if not isinstance(x, basestring): return False
x = _force_unicode(x)
if len(x) != 1: return False
if u'ぁ' <= x <= u'わ': return True
if x in u"をんー": return True
return False
class Category(object):
u"圏というものが共通に持つべき性質: 今回は空"
class SiritoriCategory(Category):
u"ひらがなしりとり圏の実装"
@staticmethod
def is_object(x):
"""引数xがこの圏の「対象(object)」であるかどうか。
ひらがなしりとり圏のobjectは1文字のひらがな。"""
return _is_hiragana(x)
@staticmethod
def is_morphism(x):
"""引数xがこの圏の「射(morphism)」であるかどうか。
ひらがなしりとり圏のobjectはひらがなで構成された空でない文字列。
>>> SiritoriCategory.is_morphism("たぬき")
True
>>> SiritoriCategory.is_morphism("たぬaき")
False
>>> SiritoriCategory.is_morphism("")
False
"""
if not isinstance(x, basestring): return False
if len(x) == 0: return False
if all(_is_hiragana(char) for char in _force_unicode(x)): return True
return False
@staticmethod
def get_domain(morph):
"""射(morphism)の域(domain)を求める
>>> _print(SiritoriCategory.get_domain("たぬき"))
た
"""
assert SiritoriCategory.is_morphism(morph)
return _force_unicode(morph)[0]
@staticmethod
def get_codomain(morph):
"""射(morphism)の余域(codomain)を求める
>>> _print(SiritoriCategory.get_codomain("たぬき"))
き
"""
assert SiritoriCategory.is_morphism(morph)
return _force_unicode(morph)[-1]
@staticmethod
def compose(m1, m2):
"""射(morphism)の合成(compose)を行う
>>> _print(SiritoriCategory.compose("たぬき", "きつね"))
たぬきつね
"""
assert SiritoriCategory.is_morphism(m1)
assert SiritoriCategory.is_morphism(m2)
m1 = _force_unicode(m1)
m2 = _force_unicode(m2)
assert m1[-1] == m2[0]
return m1 + m2[1:]
@staticmethod
def id(x):
"""object xを受け取って恒等射を返す
>>> _print(SiritoriCategory.id("あ"))
あああ
"""
assert SiritoriCategory.is_object(x)
return x
def _test():
import doctest
doctest.testmod()
if __name__ == "__main__":
_test()
||<
*1240738355*買い出し
f:id:nishiohirokazu:20090426183231j:image
-栃木県産コシヒカリ5kg 1780円
-スパゲッティ500g 105円を2つ
当分主食に困ることはなさそうである。賞味期限が近づいた55円のパンも買ってきたし。明日出かける用事があるのが嫌だなぁ。もうちょっと事前に行動するようにしないとなぁ。
野菜は難しいなぁ。たくさん買っても腐らせてしまうし。結局キムチを1パック買っただけ。逆にタンパク源は意外と問題ない。鯖の缶詰とか。ビタミン剤もたくさんあるから結局のところ「新鮮な野菜がない」っていう気持ちの問題にすぎないのか。
このあと野菜と乳製品と40%びきの冷凍ピラフ＆ミックスベジタブルを買ってきた。冷蔵庫の中が近年まれに見る充実度である。
*1240750416*整理の方法ブレスト
Twitterでブレストした内容、古くなると転記するのも面倒になるので今のうちに転記しておこう。
どうすれば部屋が片付くかをプログラマ的に考える。
まず「ものを捨てる」は最後の手段。ものを捨てれば片付くなんてのは「nの値が小さければこのO(n^3)のアルゴリズムでもかまわない」って言っているようなものだ。
よく言及される方法に「すべてのものに置く場所を作る」がある。これはO(1)でものを取り出すことのできる良い方法。鍵や財布や携帯をこの方法で整理すると外出時のオーバーヘッドが圧縮される。一方この方法を靴下に適用するのは適切ではない。靴下1, 2, ... nにそれぞれ同じサイズの領域を割り当てたりするのは容積の無駄。この場合はあふれる確率が無視できる程度に小さい「余裕のあるサイズ」の「靴下入れ」を作ってそこにつっこむのが一つの解。この設計は「個別の靴下を指定して取得することはない」という前提にたっているが靴下入れが十分に小さければ中身を一覧できるのでそこからの選択はO(1)
本がたくさんあるので透明のコンテナに詰めてみた。これはよくない設計。透明ならわかるだろうと思ったのは甘くて、背表紙があっちむいたりこっちむいたりで結局開けてみないと中身が確認できない。ただし全部まとめて段ボールに詰めるのに比べると移動しやすさの面でまだマシ。本を本棚に入れるのは前述のO(1)の方法に近い。ただし本棚はサイズの柔軟性に乏しいので大きくサイズの異なる書籍を一つの棚に入れるとパディングによって失われる空間が大きい。特に奥行き方向に無駄にされる空間の多さは問題。
いらないものを買わないのはもちろん重要だけども、問題は「いるものは買わなければいけない」という点。「部屋が本だらけなので新しい本を買いません」なんていう人は新しいものを学んで行くことができない。プログラマとしては致命的ではないだろうか。
机の上はvolatileな領域であって、長期間放置したときにそのままであることを期待してはいけない。別の作業をしているときにあふれて机の後ろに行ってしまうかもしれないし、一時的のつもりで上にものを置いたことによって極めて検索性に乏しい状態になってしまうかもしれない。机の上に出ていたものものは直前までアクセスしていた訳だから近いうちにまたアクセスされる可能性も高い。検索性を損ねる「積み重ね」がいかに悪い設計かは明らか。むしろ空の書類ケースを用意しておいて「作業中に別の作業が割り込んだら机の上のものを全部入れる」がいい。コンテキストスイッチぽい。
本をすべてO(1)でアクセスできる本棚を作るには僕の部屋は狭すぎる、という問題の解決がまだだ。この問題の解決方法はそれこそアクセス頻度の低い情報をコンテナボックスに詰めてしまうしかないかと思う。前回の失敗の原因は「透明だから大丈夫」と思ってインデックスを張らなかったことにある。「透明だから中が見える」は「箱の中が全部セーター」みたいな情報の密度が低いシチュエーションでしか真ではない。本のような個別のインスタンスにアクセスする必要がある場合はインデックスが必要。逆に言うと個別にアクセスしないなら本であってもインデックスがいらない。たとえば「箱の中全部スラムダンク」とか。
インデックスは箱が積まれた状態でアクセス可能でなければいけない。ということは側面でなければいけないということだ。
マンガや文庫本は本棚を買ったときに並べたくなるものの筆頭だが、マンガ文化について執筆中でもない限り「すばやくアクセスできる必要性」に乏しい。コンテナ行き候補筆頭。もしくは本棚の一番上や下のアクセシビリティの低い棚に配置されるべき。間違っても目線の高さとかにいれない。
インデックス自体もコンパクトにする。例えばデスノート全巻が入っている箱に各本のISBNを書いたりしない。デスノート全巻を同じ箱に入れていれば、まずデスノートの箱を見つけ出してそれから必要な巻を探せばいい。同時に読み出される傾向の高いデータはまとめるべきだしまとめることのできないデータこそインデックスが重要。
さて、箱から本を取り出して机の上などに一時的に置いて、読んだら、机の上に放置しない。たとえばまたすぐにアクセスする必要があるなら本棚へ、ないなら元の箱へ。これができるためにも本棚には常に空きスペースがなくてはいけない。
本棚に空きスペースがないと、入るべき本はどこか適当な場所に置かれることになり、システムが破綻する。本が入るべき場所が本棚とコンテナと決められているのにそれ以外の位置に本が置かれる事態は、サーバで言えばメモリ2ギガしか積んでいないのに3メガ必要になっているような状態で、本棚の奥の本を取るために手前の本をどけて、そのどけた本をまたジャマになったときにどけて、とスラッシングが発生してパフォーマンスが悲惨なことになる。そして検索性能はとても悪くなる。ギリギリではなく「新しい本が入る余地」を含めて設計する必要がある。
人間の脳は極めて信頼性の低いストレージなので脳にインデックスを格納しようとしてはいけない。A4用紙にでも印刷して壁に貼ればすむ話。問題は極めて更新頻度の高い一部の領域(冷蔵庫とか)だ。印刷が必要なシステムだとシステム運用コストが高すぎて破綻しそうだ。
おそらく本棚の一番目につくポジションは「新しくやってきた本入れ」にするべきなんだろうな。目につくと読みたくなるし。積んでしまうから読むのを忘れる。あー、しかし一つの棚にいろいろなサイズのものを入れると空間効率が…いや、いいのか。もともとその棚はきっちり詰めてはいけない棚だ。
(本棚を移動するときにルール決めない方がよかったと思った、いまはルール無しにしている、という意見に対して) 本棚を移動するときにまた別の問題があることは間違いない。しかし本棚を移動する頻度は本棚から本を取り出す頻度に比べて十分小さい。逆に、ルールを廃しても問題が起きないなら最初に導入していたルールが必要以上に詳細で維持コストの高いものだったということだ。
まあ基本的に僕の考えは「本棚を詳細に分類すべき」というもの*ではない*。むしろ本棚は視線を走らせるだけで目的のものを見つけ出せるのであまり分類の必要がない。問題は本棚が壁面という貴重なリソースを消費する関係上無尽蔵には増やせないことと、壁中を本棚にしても収まらない量の本があること。
それが本棚であるかどうかは別にして「買ってきた本が入る場所」は本を買う前にアロケートされている必要がある。さもなければ買ってきた本が積まれたり袋に入ったまま放置されることになって部屋が大変なことになる。
@hkondo それはなかなかいい方法ですね！ > 箱に年月日時分を書いて、詰められる本と一緒にデジカメで写真
ユニークなIDを振る場合に、連番整数にしようとすると「直前のIDがなんであるか」をルックアップする必要が出てきてコストが高い。日時を元にIDを作る方法はコストが安い。僕も研究ノートに最初は連番整数を振っていたのだけどもそのうち分からなくなって年月日+数字にした。
*1240762021*ブタインフルエンザSF的最悪のシナリオ
追記：タイトルを書いてから本文を書いているうちにすこしタイトルとずれてしまった。タイトル通り「最悪のシナリオ」ならもちろん全世界で新型インフルエンザが大流行して世界の人口が半分くらいになるよね。可能性は0じゃない。でもさすがにそうはならないかなーと思っている。下の記事は「もしかしたらなっちゃうかも」と僕が思うライン。
<hr>
「SF的」って書いておけばひどいことを書いても「SFですから」と言えるライフハック。
ブタインフルエンザの感染性が低くて他の大陸での発症が確認されないまま収束するか、危険ならばもうちょっと早めにその危険性をみんなが認識できるくらいのアウトブレイクが起きてくれるのが好ましかったんだがなー。
「最悪のシナリオ」は、そうなるとは思いたくはないけどそうなる可能性を否定できないようなシナリオ。たとえば崖っぷちを歩くなら「まあ、よろけなければ落ちることはないさ。たぶん無事に歩ききるさ」と思っていはいても「万が一もしかするとよろけて落ちてしまうかもしれない…」そんな不安感を感じさせるのが最悪のシナリオ。
現時点で、メキシコ、アメリカだけでなくニュージーランドやフランスでも発症者が出ていて、ある程度の感染力があることがわかる。ニュージーランドとメキシコの間を行き来する観光客と、日本とメキシコの間を行き来する観光客、どっちが多いと思う？日本国内にもすでに感染者がいて、まだ発症していない状態だと考えるのが自然じゃないだろうか。
最悪のシナリオは、その感染者たちが発症しないまま明日の通勤電車でウイルスをまき散らして感染者をかなり増やしてしまうというもの。日本政府観光局の統計によれば2008年のメキシコからの旅行者は24194人。日本人のメキシコ旅行者は69946人。合計1日あたり258人。山手線の定員は168人なので、通勤ラッシュ時の1車両の人数はおよそ300。旅行者の10%が感染していて、感染者と同じ車両に乗った人の10%が感染すると感染者総数は約800人。メキシコが発表している感染者は1324人、死者数は81人なので、同じ比率で死ぬとすると50人程度が死ぬことになる。メキシコでの死者が25～45歳の範囲だったことから死因は<a href='http://d.hatena.ne.jp/nishiohirokazu/20071229/1198903510'>サイトカインストーム</a>だろうと思われるわけで、日本でも同じように若くて元気な生産年齢を中心に死者が出ることになるだろう。
発症が確認されずみんなが油断している潜伏期間のうちにどれだけ広がってしまうか、それが問題だ。発症が確認される前から「感染者がいる」と仮定して予防をすることが重要だ。マスクや手洗いうがいはもちろん、可能であればオフピーク通勤だとか休むだとかも検討すべき。
<hr>
豚肉とかそういうことを言ってる人がいたので、あらためてはっきりと書いておこう。ブタインフルエンザはブタを発生源とした「<strong>人から人へ感染する誰も免疫を持っていない新型インフルエンザで、かつ発生源のメキシコでは現時点までに25～45歳の生産年齢を中心に感染者の16人に1人が死亡している危険な伝染病</strong>」ですよ？豚肉食べないとかそういうこと言ってる場合じゃないですよ？
</body>
<comments>
<comment>
<username>bgnori</username>
<body>スペイン風邪と同じことが起こると？</body>
<timestamp>1240768289</timestamp>
</comment>
<comment>
<username>nishiohirokazu</username>
<body>起こるか起こらないかどちらかに1000円賭けろと言われたら起こらない方にかけますけど、僕の想像より感染力が高くてタミフルが効かなければ同じことが起きてもおかしくないですね。今回のウイルスに関してはタミフルが効くことがわかっているのでたぶん大丈夫じゃなかろうか、と思ってます。</body>
<timestamp>1240804453</timestamp>
</comment>
<comment>
<username>trshugu</username>
<body>やっぱり豚肉怖いとか言ってる人がいるんだｗｗくだらなすぎて探す気にもなれないｗ</body>
<timestamp>1241142677</timestamp>
</comment>
</comments>