NAKAMURA Minoru の日記 (2013年2月)

先月の日記(2013年01月) 今月の日記(2013年02月)
2002 | 10 | 11 | 12
2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | Google+
slideshare | github | Qiita



2/28 (木)

[Movie] ゼロ・デイ・サーティ

今日はお休み。 川崎チネチッタのチケットが溜まったのでゼロ・デイ・サーティを見てきた。

[Food] ヒマラヤ@川崎

JR 川崎駅から市役所の方に歩き辛い料理で有名なネパール・インド料理の「ヒマラヤ」(ぐるなび食べログ)へ行って見る。

お店
お店

ビリヤニというメニューは初めて見るので頼んでみる。 チキン、卵、スパイスを使ったチャーハン(?)らしい。 木場公園のデイデンチュツ祭で食べたミャンマー料理が思い出される味だ。

あとジャガイモとカリフラワーのドライカレーであるアルゴビを食べる。

チャパティー
チャパティー
タンドリーチキン
タンドリーチキン
チキンビリヤニ
チキンビリヤニ
アルゴビ
アルゴビ

頼んだメニューのせいかあまり辛くなった。


2/27 (水)

[Linux] Intel CPU の NUMA I/O

Intel は Core i7 からメモリコントローラを CPU 上に内蔵し、メモリアクセスレイテンシーを縮めることにした。 マルチ CPU 構成の場合、それぞれの CPU の下にメモリがぶら下がり、別の CPU の支配下のメモリをアクセスするには CPU 間 を接続する QPI を介してリモートにメモリアクセスすることになった。 いわゆる NUMA(Non-Uniform Memory Access) である。

Core i7 は PCI Express (PCIe) のインターフェイスも CPU に持っているので、PCIe スロットも CPU の直下につながる。 マルチ CPU 構成のマシンの場合、各 PCIe スロットはいずれかの CPU につながり、CPU は自分の直下の PCIe にアクセスする場合は「ローカル」、そうでない場合は QPI 経由の「リモート」になる。

PCIe バスがどの CPU につながっているかは、まずシステム内の NUMA ノードの構成を知る必要がある。 numactl の表示を見ると、 CPU ソケットがそれぞれ個別の NUMA ノードになっていることが分かる。

$ numactl --hardware

その後で sysfs 以下からデバイスを探し、その numa_node というファイルの中を見ると NUMA ノード番号が入っている。

$ cat /sys/class/net/eth0/device/numa_node
0

numa_node が 0、1、… であれば NUMA ノード番号であり、対応する CPU ソケットが判明する。

一方、numa_node が -1 の場合は、NUMA ノード番号が取得できていないことになる。 その場合、I/O は NUMA ではなく全ての CPU から均等な位置にあるという可能性もあるが、BIOS に問題があって I/O バスの NUMA 情報がとれていない可能性もある。 ACPI の仕様では Device Configuration の中の _PXM (ProXimity Domain) で NUMA ノード番号の元になる情報が返ってくるはずなのだが。

参考


2/21 (木)

x86 のページング機構を使ったチューリングマシン

Julian Bangert 氏らによる "Page Fault Liberation Army" の発表。 副題は "It's turtles Turing machines all the way down!" で、 関連するソースコードは github にあり、発表資料の PDF もそこにある。 x86 の MMU と例外機構を使って、命令を実行せずにチューリングマシンを作るという話。 当然だが実用性はない。 また本物のチューリングマシンと比べて、内部状態の比較機能が固定されていてインチキっぽい。

ここで言うチューリングマシンを作るとは、だいたい以下の3つの機能を指している。

  • プログラムカウンターに相当するものがあって、ステップを次に進めることができる。
  • 内部状態を持つ。これは1変数だけでもよい。
  • 条件分岐ができる。上記の内部状態を判断して分岐せず次のステップを実行するか、分岐して別のステップに飛ぶかを実行できる。

もちろん x86 CPUは命令を実行することでチューリングマシンとして振舞うことが可能なのだが、今回は x86 の IA32(32 ビットモード) のページング機構(MMU)を使って命令を実行せずにチューリングマシンを作る。 初期設定が完了した後に、x86 CPU には EIP (32ビット命令ポインタ) が設定され命令のフェッチが始まるが、ページテーブルがアクセスを禁止しているので、例外が発生する。 この例外発生時にステータスが切り替わり、次の EIP が設定さらに例外が発生する。 連鎖的に例外が発生し続けて、命令は1回も実行しないのに全体として処理フローが進む。 これがチューリングマシンだそうな。

どうやってチューリングマシンを作るか?

資料を読んだ限り、以下のようにしてチューリングマシンを作っているっぽい。

  • CPU の EIP は常にアクセス違反が起こるアドレスを指している。
  • CPU の SP (Stack Pointer) はチューリングマシンの内部状態をあらわす。
  • 例外が起こった時に SS に新しい値をセットするか継続使用するかは、TSS Descriptor の TYPE ビット内の B ビットで調整する。
  • 内部状態の判断は SP < 4 だけ判定する。これ以外はできない。
  • 条件が不成立(branch-not-taken)ならば #PF (Page Fault) 例外を、条件が成立(branch-taken)なら #DF (Dobule Fault) 例外を発生させる。 つまりメモリアクセス時にページフォルトが発生すると #PF 例外が発生し SP が減算されるが、SP がゼロになるようだと #DF 例外が発生する。これで分岐の効果を作るようだ。

2/20 (水)

[Linux] LatencyTOP

Linux 専用だがプロセスやカーネル内部の遅延を計測するLatencyTOPというツールがある。

動作させるには Linux カーネルにパッチをあてる必要があるが、パッチ自体はメインストリームに取り込まれている。 ただしデフォルトでは有効にしてビルドされていないので、CONFIG_LATENCYTOP=y をつけてカーネルをビルドし直すことになる。

使用イメージ

リビルドした Linux カーネル上で latencytop コマンドを実行をすると、以下のように X ウィンドウが開かれる。

  • 左側の枠がシステムで動作中のプロセスやカーネルスレッドで、遅延時間が多い順に並んでいる。
  • Targets から選択してクリックすると右上の枠に、遅延の原因(Cause)ごとの最大遅延時間とその遅延の割合が出てくる。
  • さらに Cause をクリックすると右下の枠に、Cause のうち最大遅延時間を生じた時のカーネルスレッドのバックトレースが表示される。
LatencyTOP のスクリーンショット

VTune や OProfile のような割り込みベースのプロファイラは CPU の利用率が多いホットな部分を調査できるが、待機中に停止しているコールドな部分は調査できない。 LatencyTOP はそのような待機時間の多い箇所の調査に役立てられる。

仕組み

CONFIG_LATENCYTOP=y を有効にした Linux カーネルでは struct task_structlatency_record[32] というフィールドを追加される。 latency_record[] は以下のような struct latency_record 構造体の配列。

struct latency_record {
        unsigned long   backtrace[12];
        unsigned int    count;
        unsigned long   time;
        unsigned long   max;
};

このフィールドを使うことで、スレッドがスリープ状態になった時のスタックトレースのパターンを 32 個まで記録し、遅延時間を測定できる。

実際には /proc/sys/kernel/latencytop に 1 が書き込まれた時から、計測が開始される。 スケジューラの enqueue_sleeper でスレッドがスリープ状態になる箇所をトラップし、その時のスタックトレースを latency_record[] から探すことになる。 なければ登録する。

記録された遅延は /proc/<pid>/task/<tid>/latency を参照すると読める。 下のような行が最大 32 個まで表示される。 backtrace[] は関数名に変換されて表示される。

70 59433 4897 i915_irq_wait drm_ioctl vfs_ioctl do_vfs_ioctl sys_ioctl
 |    |    |    |
 |    |    |    +----> the stringified backtrace
 |    |    +---------> The maximum latency for this entry in microseconds
 |    +--------------> The accumulated latency for this entry (microseconds)
 +-------------------> The number of times this entry is hit

ユーザーランドの latencytop コマンドは、内部で特徴的な Linux カーネル関数のデータベースを持っている(約130関数)。 /proc/<pid>/task/<tid>/latency の各行の中に、データベースと一致する関数が出現したら、その関数が遅延の原因だと特定する。

1       vfs_read                Reading from file
1       vfs_write               Writing to file
1       __mark_inode_dirty      Marking inode dirty
...
2       __bread                 Synchronous buffer read
2       do_generic_mapping_read Reading file data
2       sock_sendmsg            Sending data over socket
...
3       tty_wait_until_sent     Waiting for TTY to finish sending
3       pipe_read               Reading from a pipe
3       pipe_write              Writing to a pipe
...
5       do_page_fault           Page fault
5       handle_mm_fault         Page fault
5       filemap_fault           Page fault

ユーザランドで遅延している場所を特定するには?

LatencyTOP で測れるのはカーネルランドでの待機なので、ユーザランドプロセスのどの箇所で停止が多いのかは分からない。

ユーザーランドに対して同じような解析をすることは可能だが、ユーザーランドのスレッドのバックトレースのうちどの関数で集計するかが難しそう。

おそらくスタックトレース中に pthread_mutex_locksemop などが出てくるが、そこで集計しても意味ある解析にならない。 pthread_mutex_lock の上に Mutex::lock のような関数があるかも知れないが、そこで集計すればよいのか? あるいはさらに一つ上に RecursiveMutex::lock があり、そこで集計すればよいのか自動判定は難しいだろうね。


2/17 (日)

[Food] マジックスパイス@下北沢

下北沢のマジックスパイス(公式食べログ)で「涅槃」のポーク角煮を食べる。

今日の相互直通運転カウントダウン

東急東横線と東京メトロ副都心線の相互直通運転は3月16日(土)。 渋谷駅に「のるるん」というキャラクターが置かれてカウントダウン中。

「どーもくんは俺が倒す」
「どーもくんは俺が倒す」

[Book] ダニエル ドレズナーゾンビ襲来: 国際政治理論で、その日に備える

Book Cover

ゾンビは吸血鬼と並ぶ二大スターで、ジョージ・A・ロメロの『Night of the Living Dead』以来、たくさんの映画・小説・漫画に登場してきた。 マレーシアでは国内で製作される映画の3分の1以上がホラーでその主役はゾンビだという。

本書はそのゾンビが発生し蔓延するゾンビ・アウトブレイクが現実に起きた場合、それを政治がどのように対処するか、対処すべきかを述べた国際政治の紹介本だ。

著者は最初ゾンビ映画から見られるゾンビの特徴の分析からはじめるが、その後でゾンビ・アウトブレイクが発生した国で各国の政権がどのような政策をとるかを紋切り型で分析する。

  • 国際政治の中で real politics の立場に立つものは、人間国家同士の対ゾンビ同盟には懐疑的である。国連のような機関が問題解決に役立つとは思わず、むしろゾンビが自分たちの立場を擁護するための場として利用されてしまうかもしれないと恐れる。洗練されたゾンビが存在する世界では人類国家とゾンビ国家の間で勢力均衡政治の出現を予見する。この場合、リアリストはゾンビ国家がゾンビがその内部で生き残った生きている人間をどのように扱おうが不干渉を貫くだろう。
  • 国際政治の中でリベラリズムの立場に立つものは、国際政治を協力しあえる非ゼロサム政治として見ている。これはアクセルロッドのゲーム理論に立脚している。「囚人のジレンマ」は互いが協力しあうと双方に利益が出ることが分かっているが必ず双方が裏切ってしまう。しかしゲームが繰り返し実行されると「しっぺ返し」戦略により裏切りが抑止され協調関係が出現する。
    ただし「ゾンビの悲劇」ゲームを考えると、ゾンビと人間が協力しあうことにインセンティブが発生しない。リベラリズムの立場に立つと人間とゾンビの同盟は不可能である。
    アンデッドは(死なないため)長期にわたって互い関わりあいを持たなくてはならないため、彼らが互いに協力しあう非常に強いインセンティブを持っている。ゾンビが他のゾンビを食べないこともここから説明できる。
  • リベラリズムは問題解決のために国際的な機関の創設・強化を行うであろう。世界ゾンビ機構(World Zombie Organization; WZO)。行動プランとして「包括的かつ統合された脱ゾンビ化戦略」が採択される。ゾンビを擁護するための非政府組織(NGO)がゾンビを抹殺することの障害になる可能性がある。そのような団体はすでに一つ実在する(「アンデッドの権利と平等に関する英国市民連」)という。Oh! NO!
    その結果、対ゾンビ政策に対する抗議が起こる可能性がある。特に肉親がゾンビになったものから。"Once you go undead, you never go back." とか "My Dad is a zombie and I love him." とかいうプラカードを持った人々がデモをするだろう。
  • アメリカの外交政策コミュニティで新保守主義、通称ネオコンと呼ばれる立場に立つものは、極めて迅速に脅威と紛争を発見する。その政策はシンプルかつ直接的なものとなるであろう。ゾンビはわれわれの自由を嫌悪する。特に人肉を喰らわなくても済む自由を。 強硬派のネオコンはゾンビに汚染された地域に対する武装侵攻を選択する。「ショックと恐怖」の軍事ドクトリンである。残念ながらゾンビはショックも恐怖もないのでうまくいかない。
  • 穏健派のネオコンはゾンビに汚染された地域に人類の前哨基地を設置すれば、ゾンビに苦しむ近隣諸国の人類が鼓舞された立ち上がり、ゾンビの抑圧から自らを解放するだろうと想定する。
  • どちらのネオコンは、全て敵は単一の悪の枢軸と想定しがちである。ゾンビ・アウトブレイクに対する初期段階での対応が、いつもの癖でイラク侵攻になってしまうことが懸念される。

真面目なのか不真面目なのか分からない調子で話は進むが、実は著者の本当の狙いは国際関係論と呼ばれる学問を、それを全然知らない読者に掴みだけでも紹介しようというものだ。 サブカルチャーを切り口にゼネコンの仕事を紹介する前田建設ファンタジー営業部を連想させる。

P.S.

随所に古典を牽強附会に解釈してゾンビに結び付けている箇所が笑える。

  • 国際政治を亡霊が彷徨っている 甦った肢体の亡霊が、脳ミソをご馳走になりにやってくるのだ。
  • 孫子が『兵法』の中で死地に臨んだ戦いの重要性に言及しているが、これは不死者の脅威を示唆している。
  • ゾンビに触れている書物にエゼキエル書、トゥキディデスの「ペロポンネソス戦史」がある。

この本の最後の著者と訳者の紹介写真を見ると、彼らがすでにゾンビになっていることが分かる。


2/16 (土)

[Android] PdaNet+

故障から返ってきた SH-12C に PdaNet(公式)をインストールする。 PdaNet は 4.0 にバージョンアップし、PdaNet+ になり PdaNet + FoxFi と合体した。 Google Play で FoxFi を購入していたためか、最初から Full Versoin Unlocked になった。

PdaNet+ 4.0 で PdaNet と FoxFi が統合されたのかが原因か動作が非常に軽快になった。 これまで PdaNet 3.5 は WiFi Hotspot ティザリングを実行すると3回に2回は SH-12C がリブートしていたのだが、普通に使えるようになった。
ばんじゃい ∩(・ω・)∩

追記:2/22

WiFi Hotspot ティザリングに途中で失敗して、バッテリを抜かない限り再起動を実行しても途中で固まってしまう現象に2度続けて遭遇。 駄目なのか。 SH-12C では駄目なのか。

SoftBank Ultra SPEED 回線をデータし放題に戻しにゆく

川崎のヨドバシカメラで SoftBank Ultra SPEED 回線を 1月19日 に「データし放題フラット」から「データし放題」に戻してきた。

前回、六本木の SoftBank ショップで切り替えた時には酷く時間が掛ったが、川崎ヨドバシでは 5 分で切り替えられた。 SoftBank ショップの iPad でオペレーションというのに無理があるんじゃなかろうか?

[Movie] ダイ・ハード/ラスト・デイ

川崎チネチッタで「ダイ・ハード/ラスト・デイ」(公式)を観てきた。 原題は A Good Day to Die Hard。


2/15 (金)


2/14 (木)

備忘

篤志家の方にクッキーをいただく。


2/11 (月)

横浜中華街へ

春節ということで賑わう横浜中華街へ。

「あかいくつ」のバス
「あかいくつ」のバス
雪の氷マンゴー味
雪の氷マンゴー味
関帝廟
関帝廟
媽祖廟
媽祖廟
手羽先を食べる鳩
手羽先を食べる鳩

2/10 (日)

[Movie] ベルセルク 黄金時代編III 降臨

劇場版ベルセルク(公式)をチネチッタに観にいく。 I部II部に続く第II部。 小さい箱なのでで3割ぐらい客が入っている。

映倫的に R18 になってしまったのをいろいろ修正して R15+ で公開したらしい。 元の R18 版よりも少し尺が短くて、R15+ 版はスタッフロールの後におまけ入っている。

今回もいろいろカットが入っておりバーキラカやワイアルドが出てこない。 ドラゴン殺しも登場しないのだが、この先の映像化するとしたらどう接続するのかしらん。


2/9 (土)

[Movie] アウトロー

チネチッタで「アウトロー」を観てきた。 原題は Jack Reacher。 英国の小説のシリーズらしいが、日本での知名度がないのでこのような名前になったっぽい。 とはいえ主人公はそれほどアウトローではない。


2/6 (水)

[時事] ソロモン諸島で M8.0 の地震

南太平洋のソロモン諸島の現地時間6日正午過ぎ(日本時間6日午前10時過ぎ)にマグニチュード8.0の地震が発生。

2009年9月29日にやはり南太平洋のサモアでM8.3の地震が起きている。 近いといえば近いが、2,000kmぐらい離れている。


2/3 (日)

エル・グレゴ展

上野の東京都美術館でエル・グレゴ展を観てくる。

エル・グレコはディエゴ・ベラスケス、ゴヤとともにスペイン三大画家と呼ばれているそうだが、私はこの展覧会までエル・グレコのことを知らなんだ。 エル・グレコは本名をドメニコス・テオトコプーロス。 1541年にヴェネツィア共和国支配下のクレタ島に生まれる。 ヴェネツィア共和国支配下のクレタ島はギリシャ正教とカトリックが混在していたみたいだが、エル・グレコは最初イコン画家になったというから正教系の人なんだろう。 後にイタリアのヴェネツィアを経てスペインのトレドに定住する。 スペインでは宗教画や肖像画を多数残している。

同じ上野公園の敷地内にある国立西洋美術館のプラド美術館所蔵 ゴヤ 光と影で観たのを思い出したが、 肖像画に関してはゴヤや同時代のスペインの画家とエル・グレコの画風には共通点が多いように思われるが、宗教画や宮廷画は随分と異なっている。


2/2 (土)

[Movie] テッド

川崎チネチッタでテッドを観てくる。

テッドの封切が1月18日からすでに2週間近く経っていると言うのに、チネチッタの中ぐらいの箱が半分以上埋まっている。 最近のチネッチの洋画の公開日初日よりも客の入りが多いぐらいだ。


2/1 (金)

Scripting GDB using Python

GDB に一連のコマンドをスクリプト実行する方法がある。 これは複雑なデータ構造の可視化(STL GDB evaluators/views/utilities)やテストの自動化のために使われる(ファイヤープロジェクトGDBによるテスト自動化への試み)。

ただし GDB の scripting は表現能力が低いので、複雑なロジックを書こうと思うと面倒である。 最近の GDB には Python でスクリプトを記述する Scripting GDB using Python が入っている。

とりあえず GDB の gdb/testsuite/lib/gdb.exp にある gdb_breakpoint [gdb_get_line_number "keyword"] のような、特定キーワードのある行にブレークポイントをかけるスクリプトを作ってみる。

break_at_keyword.py:
import gdb

def break_at_keyword(keyword, file):
    linenum = 0
    for line in open(file, 'r'):
        linenum += 1
        if (line.find(keyword) != -1):
            command =  "b " + file + ":" + str(linenum)
            print command
            gdb.execute(command)

テストプログラム。

test.c:
#include <stdio.h>

int main(int argc, char** argv)
{
    char* p = 0;
    int f = 0x80000;

    printf("%p\n", p + f * 4096); // TEST:001
    return 0;
}

スクリプトを実行。

$ gcc -g test.c
$ gdb a.out
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6)
... snip ...
(gdb) source break_at_keyword.py
(gdb) python break_at_keyword("TEST:001", "test.c")
b test.c:8
Breakpoint 1 at 0x4004e2: file test.c, line 8.

なんとか任意の位置にブレークポイントがかけられた。

後はモリモリ GDB を自動実行するスクリプトを書くべえ。

追記

いろいろな調査(8月27日の日記)を含めて、break_at_keyword.py の完成版を作成。 以下の関数が使える。

  • break_at_keyword(keyword, filename, offset, comment_remove)
  • break_at_keyword_in_function(keyword, fname, offset, comment_remove)
  • break_at_keyword_after_position(keyword, position, filename, offset, comment_remove)
  • break_at_keyword_before_position(keyword, position, filename, offset, comment_remove)

使い方は以下の通り。

  • 環境変数 SOURCE_ROOT にディレクトリを指定すると、filename はそのディレクトリ以下から探す。
  • keywordcomment_remove が False 以外では、filename 中のコメントを除いた部分からのみマッチする。
  • keyword が C/C++ の識別子にみえる場合には、シンボルとしてマッチする。"send" を指定すると sendmsg() にはマッチしない。"send(" と指定すると resend にマッチするようになり、間に空白文字の入った send ( という記述にはマッチしない。
  • offset にはマッチ行に対して、ブレークをおきたい行をプラスマイナスできる。省略すると 0 になる。
  • commnet_remove をすると、keyword はコメントも検索対象になる。
  • break_at_keywordkeyword が最初にマッチした行 ± offset にブレークを張る。
  • break_at_keyword_in_function は、fname にマッチする関数のエントリポイントから検索をはじめる。 keyword にマッチする行が見つからなければ、関数を越えて検索が続く。 ただし関数を探すのは gdb の機能なので、fname が複数あるとうまくいかない。 その場合は filename:function という形で指定すると動く可能性がある。
  • break_at_keyword_after_positionposition に指定された文字列にマッチした行以降で、最初に keyword が見つかった行 ± offset にブレークを張る。position はコメントも含めて、検索される。
  • break_at_keyword_before_positionposition に指定された文字列にマッチした行までで、最後に keyword が見つかった行 ± offset にブレークを張る。

先月の日記(2013年01月) 今月の日記(2013年02月)
2002 | 10 | 11 | 12
2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | Google+
slideshare | github | Qiita


Written by NAKAMURA Minoru, Email: nminoru atmark nminoru dot jp, Twitter:@nminoru_jp