2011年02月

人間は複数の場所に同時に存在できません．同時刻に別々の場所の仕事を一人の人間に割り当てるという理不尽があってはなりません．上位の人間は，誰が何担当で何処でどれだけ時間を消費するかを把握することが必要です．

また，既に誰かが終えている仕事を，その事実を把握せず他の人間に再度割り当てるのも避けるべきである．特に，既に割り当てられた別の作業を離れた場所で実行中の人間に対して，その終えられたはずの仕事を割り当てるために，状況確認もせず要件も何も告げずただただ緊急に出頭せよとの電文を送ることは行われるべきでない．そのような理不尽な緊急出頭命令は，その人間が重大な不手際を行った時以外になされるべきではないし，ましてや，その終えられたはずの仕事が緊急出頭を命じられた人間以外にも可能な仕事であれば，尚更である．

とどのつまり，重大な不手際があったのかと物凄く不安にせられ雨中を全力疾走させられたうえに，急いで現場についてみれば，状況の説明なども特に何もされず既に終えられた簡単な仕事をやってよと至極てきとうに言われただけ，という状況が物凄く気にくわないということ．何のために準備のミーティングしたの？　ザルすぎるでしょ．突然わいた仕事でなく前から分かっていたものなのだから，そんな仕事は前もって誰かにアサインしておくものでしょうに．あと，要件も何も書かない緊急の出頭命令を出すのではなく，この仕事を振りたいんだけど手は空いているかと聞くのが筋でしょうに．その仕事が別の人間によって完了していることを（たまたま）私が知っていたのだから，問合せに修了済みと答えるだけで話は終わっていた．そうでなくとも，仕事内容さえ分かれば現地にいる人間にヘルプを頼む指示を私が出すだけで済んだはず．全くもって無駄過ぎて非常に遺憾．意味もなく緊急の出頭命令食らって元の作業が中途半端になったのも非常に遺憾．

閑話休題．

懐かしいメンバーに会えたのは良かった．

昨日の晩，ここんとこ暖かかったので桜も咲いたかなと思って河津町の河津桜開花情報をみた．そしたら満開とか書かれていたのでそのままの勢いで見に行ってみた．前回は伊豆半島の西海岸から回っていったけれど，今回は時間もないので東名から国道136経由の天城越えで河津に行くことにした．幸いにして今朝も暖かかったので路面凍結もなく無事に現地に着けた．ループ橋も久々に通った．

例によって例のごとく日の出前に現地に到着したので夜桜をば．

陽が射す前の遠景．川辺は桜色に染まってた．

桜のトンネルもまあまあ．朝早いのに人が結構いたのでトンネルが無人になることはなかった．

そして日傘してきた頃．朝日で赤みが増すので暖かくなった感じ．このころになると川原に降りる人々も沢山．

後は近景～アップ．河津桜は葉っぱと花とが同時にあってこそだと思う．

そんで例のごとく普通の人が動き始める８時には現地を去る．８時ごろには駐車場も結構スペースが埋まってて，おっちゃんがひとりで集金と案内を頑張っていた．ということで，駐車場代500円を払って東京へ出発．帰路も天城越えで行くことにしたのだけど，反対車線は修善寺ぐらいまでほとんど車が途切れることなく続いていた．夜明け前に行くか電車で行くのが正解なきがする．海岸沿いはどうなっていたか確認しなかったけど．

監督者的意味で．

理科の物理は分かるけどそれ以外は分からないことが多いなぁ…　物理は数式として定式化された原理を使えば答えが出るので簡単．昇圧回路（Cockcroft–Walton回路）とかの問題も出てて楽しい．

今ひとつはっきりとしないのだけど，Cockcroft–Walton回路ってチャージポンプに含まれるのかなぁ．電化を上のコンデンサに送っているって点では同じだと思うのだけど，送り方が微妙に違うので別物か？　よくわからん．

よく考えたら奥多摩湖へバイクで一度も行ってないなぁと．天気予報を見る限り今朝は天気が良さそうな割に寒くなさそうなので行ってみた．

寒くなくてもところどころ凍ってたけど：

例のごとく日の出を撮りたかったのだけど，よく考えたら冬なので谷間から日が登ってくれない．ということで，朝焼けのみ：

山から出てきたころには赤くも何とも無い：

赤いといえば隣にあった橋：

奥多摩湖の後は山梨県道18号と522号を経由して中央自動車道で帰って来た．18号は思いの外走りやすい道路だった．522号の途中にはきれいな富士山が見れるところがあった：

ほんとは松田の河津桜を見に行った気がしたのだけど，ヤビツ峠越えるのが面倒になったというオチ．

研究室のある階の逆側の非常階段踊り場にタバコの吸殻が落ちまくっている．事務から何度か注意をせよとのお達しがあり，この建物に入っている研究室では注意がなされているはずなのだけど…　掃除中に大量の吸殻が見つかって最近事務が注意を流してそれ程経たずに以下のとおり．吸殻と火を踏み消した跡と．

試しに上下の階の踊り場も見てみたけれどそこらは非常に綺麗だった．この踊り場だけ汚い．上下階からわざわざ移動してきて吸っている可能性もなくはないけれど…　この階の住人って身内なのよね．身内なら張り倒したい所存．

ついでに喫煙所にゴミを置いていくバカも張り倒したい．火を広がりやすくするとか何考えてるんだろう？　火消し用の水を入れたペットボトルが常備されているのが問題かも知れないけど．

時間的制約がきつくない場合，「他の人に作業を正確にやってもらうこと」と「自分で作業しちゃう」ってのの労力ってあまり差がない気がする．つか，説明している間に同時に自分の手を動かせば説明する時間で作業が終わってしまうので時間的制約も関係ないかも．

ということで，説明に要する時間は短いけれど作業の時間は長いという仕事が多くないと並列処理できない．あたりまえか．

曰く，「認証サーバへのアクセスを学内からに限ることは技術的に難しいと専門家が言っている．なので無理．」

何が難しいのだろうか？　学内には学内からのアクセスしか認めないサーバが沢山あるのに．専門家ではない私には理解しがたい．

「ネットワークの管理者が難しいと言っている」なら納得．管理者にしか分からない現場事は多々ある．

どうでもいいけど．

ところで，この専門家ってのはどういう人間を指すのだろうか？　たぶん，ネットワーク管理の専門家ってことだとは思うのだけど，それって何ができたら専門家？　情報処理技術者試験のネットワークでも持ってればいいんかね．

今日は一ヶ月後のミーティングのための作戦会議．書類の用意が色々と面倒だよね．出張がもう少し簡単になるとありがたい．

バイクの洗車を終え，水を拭き取るのに使ったウエスを入れた袋を右手に下げ，大通りから一本内側の道を歩いていた．そしたら，後ろからやってきた二人のり（２種？）原付スクーターにウエス入りの袋をひったくられそうになった．

前から歩いてきた爺さんを避けようと道の左によったのが敗因．その直後に，バイク来たなー　→　何か袋が引っかかったなー　→　引っ張られてるなー　→　袋をちゃんとつかんで引き寄せよう　→　バイク逃走　→　むかつくからしばらく走って追いかける　→　人間の足では原付に勝てません．

赤羽岩淵病院の裏あたり，１８時３０分頃．暗かった＆私の目が悪いのでナンバーは見えず．残念．ウエス入りの袋を盗られてたほうが話としては面白かったのかも知れない．

とりあえず，荷物を手に持って歩くときは建物側に持っておきましょう．小道ではなく大通りを歩きましょう．後ろからバイクが近づく音がしたら振り返って確認しましょう．変に近づいてきたらケリを入れましょう．スタングレネードぐらい用意しておきましょう？

犬吠埼で日の出を拝もうと出発．ついでに鋸南町の河津桜（頼朝桜）の様子見に行くことに．結局房総半島を海岸線に沿って約一周した（西側は面倒になって館山自動車道に乗ってしまったけど）．４５０キロくらいで１２時間くらい？

ということで犬吠埼の灯台．寄り道してたら意外と時間食って到着時には日の出直前．ちなみに房総半島最東端とのこと．

で，日の出．天気が良さ気なので期待していたけれど，またもや海から直接の日の出は見られなかった．けどまあ，これまでで一番低い位置で雲から出たのでそれなりに満足．低い位置だと赤さが違う．

おまけで満月．地球の丸く見える丘展望館の近くで撮影．展望館自体は当然のごとく閉まってたので路上から．暗い夜の満月の月出とか良いかも知れない（無理）．

あとはひたすら館山経由鋸南町へとひたすら海岸線を走行．強風のため砂浜近くでは砂が飛びまくりバイクのボディに砂がこびりつく．そんな状態なので給油のためにタンクバッグをずらしたら傷が……　細かいキズはもう気にしない．折を見てまたコーティングすりゃいいや．

道中，房総半島最南端の野島埼と房総半島最西端の洲崎によった．これで残すところは房総半島最北端のみ．……どこだろ？

そんで，鋸南富山のICから佐久間ダムへ向かおうとしたらいつもの道が全面通行止．しょうが無いので迂回路へ．この時期は桜の見物客も増えてきているので迂回の車がそれなりに連なって迂回路を進む．んで，先頭の車が迷う．

結局無事に佐久間ダム湖に着いたけれど，桜はまだまだだった．残念．規模も今ひとつどの程度なのか分からず．水辺である必要がなければ松田に行くほうが良いかも知れない．元気があれば河津町が良いけど伊豆半島は高速道路的意味で発達不良なので悩ましい．

死亡保障が終身な掛け捨てで短期払いの保険はないものか？　まあ，解約払戻金を減らした低解約返戻金型終身保険は存在するのでそれがそうであるといえばそうなのだけど．あれって減らし具合が微妙なんだよな…

結局のところ，積立型で短期払いな終身保険って意味ないような気がしてきた．解約してお金返って来ても保障自体がなくなってしまうので困る．なので解約できないしお金も手元に戻せない．掛け捨てにして余ったお金を別途運用し続けるのがマシ．

まあ，定期払いで終身保障にするための上乗せ分だと思えば妥当なのだけど．

うーん，具体的なモデルとパラメータが欲しい．

昨日，複数のターミナルにコマンドをインタラクティブに実行する方法を適当にでっち上げたのだけど，それと似たことが出来る cluster SSH というものを教えてもらった．せっかくなのでちょいと試しに使ってみた．sudo apt-get install clusterssh で用意完了．

cluster SSH は、複数の ssh 接続を作って，それぞれにターミナルを用意して，もうひとつのウインドウにあるテキストフィールドへの入力を選択したターミナルにインタラクティブに送ってコマンドを実行できる．入力を送り出すターミナルの集合はGUIから選択できる．また，あとから ssh の接続を増やしたり減らしたり出来るみたい．

んで，cluster SSH だと，上矢印キーとかCrtl-Rとかのコントロールコードも即座に送ってくれるため，過去のコマンドを呼び出すのが一斉に簡単に出来る．これは良い機能．……それぞれのターミナルでヒストリが違う時には非常に困るけど．

昨日の方法だとコントロールコードを送るとか面倒だし１文字ずつ送るのも工夫がいる．

一方で，cluster SSH だと，for 文を回して各ターミナルに微妙に異なるコマンドを送り付けるという技が出来ない気がする．あと，コマンドを送り付けるターミナルの選択をスクリプトで自動的にやるとか出来ない気もする．そもそも，コマンドを入力するテキストフィールドに機械的にコマンドを投げ込む方法が分からない．

ということで，クラスタに対して均一な操作を加えるときには cluster SSH は非常に便利そうだなぁという印象．ソフトウェアのインストールとか．でも，変態的な使い方が出来そうに見えないのでつまらない気もする．

いつも履いている靴がどこも売り切れ中．ちょうど欲しいサイズがメーカー在庫無し．モデルチェンジでもするのかたまたま品切れなのか…　何れにせよ今履いているヤツはつま先の底がかなりすり減ってしまっていて，歩行中地面を蹴るときに滑りまくって効率が悪い．昨日の雪でも結構滑ったし．

靴の新調は確定として，別の靴にするかどうかが悩ましい．

今回の論文を書くための実験で，複数のHadoopのクラスタセットひとつひとつに対応するターミナルを開き，それぞれで似たようなコマンドを実行して実験結果を取るという作業をした．コマンドをカットアンドペーストで全部のターミナルに張り付けて実行するとかバカすぎる．なんとかしたい．

という背景で，複数のターミナル（シェル）に対して一箇所から機械的にコマンドを打ち込みたい要求に駆られた．pssh とかだとインタラクティブに出来ないし，そもそも出力のためのターミナルは複数のウインドウにわかれていて欲しい．やりたいのは入力の一本化だけ．

単純に考えると，fifo を使って入力ターミナルからのコマンドを出力ターミナルの標準入力に送ればいい気がする．なので，とりあえず，出力用ターミナルで

cat pipe | bash

としておいて，入力用ターミナルでコマンドを

echo 'cd hoge' > pipe
echo 'ls' > pipe

とかやって送り付けようとした．

が，失敗．何故かコマンドをひとつ発行しただけで出力ターミナルの bash が終わってしまう．これでは複数のコマンドをインタラクティブに発行できず，psshと変わらない．これは望むものではないので原因を探って手法を改善せねばらない．

上の単純な仕組みが失敗した原因は次の通り：最初に送られたコマンドを出力側の bash が読み込んだとき，pipe が EOF に達してしまって "cat pipe | bash" のコマンドが終了してしまう．pipe には後から内容が追加されるけど，とりあえず最初のコマンドの後に一度はファイルの終端まで達するので，シェルのパイプが終了してしまう，と．

さてどうしたものか．

適当に検索してみたら同じようなことを考える人はいたようで，解決策が見つかった．"cat pipe | bash" の代わりに次を使えばいい．

tail -f pipe | bash

この tail の -f オプションは，EOFに達しても tail を止めずEOF後に追加された内容も後ろに吐く，という指定．手前のコマンドの出力のプログレスを表示するとかの目的に使われるオプションらしい．これをやっておけばコマンドを間隔を置いて複数送り付けることが出来る．

ということで，前準備＠入力ターミナル：

ps="1 2 4"
for p in $ps; do mkfifo pipe-$p; done

前準備＠出力ターミナル達：

tail -f pipe-1 | bash

tail -f pipe-2 | bash

tail -f pipe-4 | bash

あとは，適宜全部のターミナルに対して for 文使って少しずつ違うコマンド送ったり，一斉にコマンド発行したり，特定のターミナルにだけ cat 使ってインタラクティブに仕事したり，tee と合わせて特定のサブセットにだけコマンドを送ったり，等など．それなりに使い勝手が良い気がする．

for p in $ps; do echo "procs=$p" > pipe-$p; done
for p in $ps; do echo 'this is pipe-$procs' > pipe-$p; done
for p in $ps; do echo "./runExp.sh" > pipe-$p; done
...
cat | while read line; do echo $line; done > pipe-4
...
cat | while read line; do echo $line; done | tee pipe-2 | tee pipe-4
...
for p in $ps; do echo "cat result-$p.txt" > pipe-$p; done

cat の while read line は１行単位でコマンドを送るため．ここらへんは関数を定義しておいたほうが頭よさげ．

あとは最初のセットアップのところを for 文でいけると楽．ということで，出力ターミナルを一斉に作ってパイプをつなぐコマンド：

for p in $ps; do (echo "(echo 'echo this is pipe-$p'; tail -f pipe-$p) | bash" > pipe-$p &) ;( gnome-terminal -x bash pipe-$p &); done

これで満足．

ひとつのファイルは HDFS 上に物理的にチャンクに区切られて置かれる．FileSplit はひとつのファイルを論理的に区切ったもの．ひとつの FileSplit に対して Map のジョブひとつが対応して実行される．細かくは，ひとつの FileSplit がひとつの RecordReader を生成し，その RecordReader がその Map ジョブへと Key/Valueペアのリストを提供する．このとき，その RecordReader はその FileSplit で指定された論理的な領域を越えて（HDFS上にあるだろう）元のファイルを読み込むことが出来る．

一般に，HDFSのチャンクはFileSplitではないし，FileSplitとMapジョブに提供される仕事とは完全に一致はしない．

実際，デフォルトのTextInputFormatが作るRecordReaderは，与えられたFileSplitの最終行を完成させるため，次のFileSplitの境域へと境界を越えて最後の行を読みに行く．例えば，改行なしの大きなファイルを入力とすれば，最初のFileSplitから作られたRecoardReaderは改行を求めてファイル全部を読んでしまう．結果として，先頭のMapジョブはファイル全体を入力として受け取る．

大体にしてインストールというかセッティングが面倒なので手順のメモ．

1. ダウンロードして展開．クラスタの場合，本体の置き場所は NFS 上にしとくとインストールが楽（ログのディレクトリに注意）．さもなければ全マシンの同じパスに置いておくべし（パスをマシンごとに変えていいのかどうか分からん）．

   wget http://ftp.kddilabs.jp/infosystems/apache//hadoop/core/hadoop-0.21.0/hadoop-0.21.0.tar.gz
   tar xfvz hadoop-0.21.0.tar.gz
   cd hadoop-0.21.0

2. 環境ファイル conf/hadoop-env.sh の編集：JAVA_HOME と HADOOP_HEAPSIZE と HADOOP_LOG_DIR．

   ログの出力先はデフォルトで hadoop の置いてあるディレクトリ(HADOOP_HOME)の下の logs ディレクトリなので，これが NFS 上だったりすると酷いことになる．なので，ローカル上に取るように指定を入れておく．

   export JAVA_HOME=/usr/lib/jvm/java-6-sun/
   export HADOOP_HEAPSIZE=2048
   export HADOOP_LOG_DIR=/tmp/user/node000/logs
   

3. 設定ファイル conf/slaves：計算に使うノード名を列挙．

   node000
   node001
   node002
   node003
   ...
   

4. 設定ファイル conf/core-site.xml の編集．

   namenode として使う計算機の名前（URI）を書いておく．マルチコア計算機１台なら localhost で十分．クラスタの場合には localhost ではまずいので，ちゃんとした計算機名前を書いておく．

   <configuration>
        <property>
            <name>fs.default.name</name>
            <value>hdfs://node000:9000/</value>
        </property>
   </configuration>
   

5. 設定ファイル conf/hdfs-site.xml の編集．

   dfs.name.dir と dfs.data.dir に /tmp とかローカルなディスクのパスを書いておく（設定書かなくてもデフォルトで /tmp に適当なディレクトリを作って使ってくれるけど）．NFS上のパスを指定するのは何考えているか分からない．あとは dfs.blocksize （HDFS上のチャンクのサイズ）を適当に変えてもいいかも知れない．Mapper への一仕事の最大値はこのサイズ．

   <configuration>
        <property>
            <name>dfs.name.dir</name>
            <value>/tmp/user/node000/name-dir/</value>
        </property>
        <property>
            <name>dfs.data.dir</name>
            <value>/tmp/user/node000/data-dir/</value>
        </property>
        <property>
            <name>dfs.blocksize</name>
            <value>4194304</value>
        </property>
   </configuration>
   

6. 設定ファイル conf/mapred-site.xml の編集．

   とりあえず，mapred.job.tracker に JobTracker のいる計算機の名前を書いておく．マルチコア１台なら localhost で十分．クラスタなら計算機名をちゃんとかく．あと，計算が軽い時には JVM を使い回さないと遅くて困るので mapred.job.reuse.jvm.num.tasks に無限回の使い回しを意味する -1 を入れておく．ノード一つ当たりのジョブの数は mapred.tasktracker.map.tasks.maximum と mapred.tasktracker.reduce.tasks.maximum で指定しておく．マルチコアならコア数以上のジョブが同時にあって構わないので，コア数以上の数字を書いておく（2コアマシンしか無いのに200とか書くとプロセスが多すぎて死ぬ）．また，Hadoop ではひとつのファイルを複数の FileSplit に分割し，その FileSplit １つに対して Mapper が１つ呼ばれて動く（間に RecordReader が挟まって「FileSplit→KVペアの集合」という変換が入るけど）．その FileSplit のサイズ指定が mpreduce.input.fileinputformat.split.maxsize でできる．実際には，これで指定したサイズと HDFS のチャンクサイズとの小さいほうが実際の FileSplit のサイズになる（全タスク数の指定を入れたときには，さらにそこから導かれるサイズとの小さいほうかね）．

   <configuration>
        <property>
            <name>mapred.job.reuse.jvm.num.tasks</name>
            <value>-1</value>
        </property>
        <property>
            <name>mapred.job.tracker</name>
            <value>node000:9001</value>
        </property>
        <property>
            <name>mapred.tasktracker.map.tasks.maximum</name>
            <value>2</value>
        </property>
        <property>
            <name>mapred.tasktracker.reduce.tasks.maximum</name>
            <value>2</value>
        </property>
        <property>
            <name>mapreduce.input.fileinputformat.split.maxsize</name>
            <value>4194304</value>
        </property>
   </configuration>
   

7. テスト．

   namenode を初期化して，他のノードを起動して，最初にディレクトリ作って，そこにファイルを転送して，サンプル動かして，出力確認して，邪魔な出力消して，そしてノード停止．

   bin/hadoop namenode -format
   bin/start-all.sh
   bin/hadoop fs -mkdir input
   bin/hadoop fs -put conf/* input
   bin/hadoop jar hadoop-mapred-examples-0.21.0.jar grep input output 'dfs[a-z.]+'
   bin/hadoop fs -cat output/*
   bin/hadoop fs -rmr output
   bin/stop-all.sh
   

これで言う事聞くようになった．

その他無茶な設定 in conf/mapred-site.xml：なるべくディスクつかなわいように無理をする．

     <property>
         <name>io.sort.record.percent</name>
         <value>1.0</value>
     </property>
     <property>
         <name>io.sort.spill.percent</name>
         <value>1.0</value>
     </property>
     <property>
         <name>io.sort.mb</name>
         <value>4</value>
     </property>
     <property>
         <name>mapred.inmem.merge.threshold</name>
         <value>2048</value>
     </property>
     <property>
         <name>mapred.job.reduce.input.buffer.percent</name>
         <value>1.0</value>
     </property>
     <property>
         <name>mapred.job.shuffle.input.buffer.percent</name>
         <value>1.0</value>
     </property>
     <property>
         <name>mapred.job.shuffle.merge.percent</name>
         <value>1.0</value>
     </property>

安田講堂前に立派な雪像が出来ていた．

誰が作ったか分からないけど，雪の台座（高さ１ｍ位）を作っているところが秀逸．雪像自体も気合が入っている．携帯のカメラなのが残念…

ラインごとに Mapper に渡さなくていい，まとめて寄越せ　→　自前で FileSplit 全体を Mapper に与える RecordReader を実装．中身はすっからかんだけどね．

bin/hadoop namenode -format して bin/start-all.sh して bin/hadoop fs -put hoge.dat . とかすると文句を言われる　→　bin/hadoop fs -mkdir tmp してから bin/hadoop fs -put hoge.dat . すると文句を言われない．からの状態からディレクトリを何でもいいからひとつ作ってやると，ホームディレクトリ（.）にファイルを置ける．というか，mkdir でディレクトリ作ったときにホームディレクトリもついでに作られるからなのか？　とにかくディレクトリを先に作っておかないとファイルを置けないのかね？

mapreduce の FileSplit のサイズは mapred-site.xml でmapreduce.input.fileinputformat.split.maxsize を指定．

bin/hadoop --config conf-hoge ... とかで設定ファイルを切り替えられる．start から stop まで一貫して同じ設定を使わないと色々とおかしくなってくれるけど．

曽我の梅林へ梅を見に行った．１０時過ぎには大学にいく必要があったので，日の出前に梅林に到着．路面が凍結しているので危ない．特に止まった時が一番危ない．気を受けないと付いた足が滑って立ちゴケする．コケなかったけど．走行距離２００キロ．

んで，別所梅林．ここらの梅林全体をまとめて曽我梅林と呼んで，別所梅林はその中のひとつってことでいいのかな．よく解らんけど蘇我の梅林に行こうと言っていつも来ていたのはここだったはず．

雪の降った翌日の早朝なので，寒いシリーズ：赤富士，雪をかぶった箱根の山，朝日．

蘇我の梅林は好き勝手に入り込める点が良い．好きなように梅が見られるし，地面の草も良い感じ……　寒すぎて凍ってたれど．昼間ならきれいな緑の地面と青い空と白い梅とか撮れるはず．でも地面が凍っているので白い梅と早朝の青空．

そして帰りの東名高速で事故のために渋滞発生．おかげで大学に行くのが微妙に遅れてしまった．迷惑だから自爆でも事故るな．

Hadoop のオンラインドキュメントが腐っていたというオチだったのだけど…　HDFS へのディレクトリの転送がおかしい気がする．

さて，次はファイルからの読み込み部分をカスタマイズしにかかろう．FileSplit の境界を超えた部分の扱いが今ひとつ理解出来ていないのだけど…　自分で実装するときにはどうやって境界超えた端数を持ってくるんだ？

上野の Kinko's は土日祝日でも大判印刷（フルサービス）を24時間受け付けているのでありがたい．学会発表のポスターを切羽詰った状態で印刷するのに特に有効（事前に電話で連絡しておかないとオペレータが休みで時間かかるとかあり得るけど）．

ということで，雪の中印刷をお願いに行った．午後2時少し前に受け付けて午後4時少し前に出来上がりの電話をもらったので，A2サイズ8枚で2時間という結果だった．雪の降る中を大学から往復するには微妙な時間だったけど…　予定より早い仕上がりで良かった．

上の組織から最終講義用のポスター作れと仕事が降ってきたので，作った．ボス曰く「無駄な背景いれず白地に黒文字でいい」とのことだったので，真っ白に大きな黒文字で必要事項しか目に入らない，という方向で作成．デザインは引き算だとか言われたりするけれど，宣伝に余計な情報は入れないほうが良いよね．

で，作成途中に降ってきたコメント：葬儀の案内みたにはならないようにお願いします．

……

世間一般に白黒ってのは葬式というか弔事・凶事のイメージなのだろうか？　まあ，確かに，白黒の鯨幕とか多くの人は葬式でしか見たことがなく，「白黒＝葬儀」なのかも知れない．そして慶事には紅白と．

でも白黒の鯨幕って本来は弔事・慶事に関係なく使用されてたのもので，皇室や神社では慶事に使用していたりするとのこと：氷川神社のページ，wikipedia．

黒＝高貴とかのイメージかね．綺麗な黒を得るのは難しく，厳かな感じだと思う．綺麗に極まった白黒は美しい．

とはいえ世間的には白黒が葬儀だというのは変わらない事実．でもまあ，光沢紙使えば葬儀の案内には見えないよね．フォントも楷書体と行書体を使わず濃い黒色にすれば葬儀の案内にはなるまい．あとは横書きにしておけば大丈夫なはず．

光沢紙にゴシック体の横書きで書かれた葬儀の案内はなかろう．

上の組織から突然何が降ってきても対応できるように構えるってものすごく大変だよなぁ，と．上から降ってくる仕事が事前に分かっていれば楽なのだけど．そうでもないから色々と想定して動かないとならんのでコストが高い．

ということを考えてたのだけど，これってオートマトンの並列化っぽいよなぁ，とかふと思った．逐次に計算すると現在の状態一つだけ覚えておけばいいから楽．並列にやるには手前の計算の結果がどの状態で終わってもいいように全部の可能性を計算しておく必要がある．まさに今の我々の状況そのもの．コストが高い．

ssh 以外をシャットアウトしたい．iptables 直打ちはめんどい．

ということで，ufw とかいう便利なものを知った次第．有効にしてポート開けて終わり：

sudo ufw enable
sudo ufw allow 22

そして ufw は Uncomplicated Firewall の略でたしかに名前通り簡単だなぁと．

例えば，試験開始後４５分で試験会場に着いたのならば，１時間早い電車に乗っていれば試験に間に合ったであろう．実際，今日の東京近郊の遅延は最大５０分（常磐快速線）だったのだし．電車の遅延なんか頻繁に起こるのだから，試験日くらい早起きして余裕を持って大学に出てくればいい．そんなことも出来ずに遅刻したのであれば，それはただの遅刻でしか無いだろう．始発で来たが間に合わなかったとか言うのはしょうがないと思うけれど．

何かと言うと，リスク管理くらい自己責任でしておけと．その努力もなしに救済ばかりを要求すんなと．

とどのつまり，メールサーバが機嫌悪いこともあるのだから，論文投稿サイトのアカウント登録は余裕を持って早めに行っておけと．そして，学位論文の提出用ベータ版印刷も早めにしておきましょうと．何時何時誰かがマンデルブロの描画をプリンタに投げるかも知れないのだから．

さくらのVPSを試しに申し込む　→　Ubuntu 10.04 LTS i386 に入れ替え　→　sshd を public-key 認証にしてポートそのままで起動　→　一日で１万回弱の攻撃！

９ヶ所くらいのIPから攻撃されたらしい．

攻撃されたユーザ名は1400通りくらい．admin のバリエーションが微妙に面白く，admin0, admin1, admin12, admin123, admin1234, admin2, admin3, admin321, admin4, admin5, admin6, admin7, admin8, admin9, admina, admine とか．admin321 が攻撃対象になっているあたりが面白い．同様に backup も 0 から 9 まで揃ってた．そして大抵は英語名なのだけど，ほんの少し日本語名も入っていて，matsuokaとかどこから辞書に入ったのやらと思う．そして tanaka はあったが sato と suzuki は今のところ無かった．

攻撃元のIPから国を調べてみると，タイが４つ，チリが１つ，韓国２つ，日本が２つ．このなかでも日本の２つは他のさくらのVPSのサーバだったりする．攻撃されて bot に感染したのだろうか？

さて，これ以上通常ポート使ってても面白いことなさそうだからさっさとポートを変えてしまおう．

点検も終わったので久々に旅に出た．目的地は伊豆半島の南（南東）端の爪木崎．東京から出て伊豆半島一周して東京へ戻って480kmの12時間．御殿場が寒かった…

で，爪木崎の一つ目の目的：海から日の出．完全に海から上がったわけじゃないけど８割方納得．

そして爪木崎の二つ目の目的：水仙．爪木崎は水仙の群生地として有名なわけだけど，これまで一度も見たことなかったので見てみたかった．早く咲いていたであろう部分は葉が枯れだしていたけれどまだまだ見頃でよかった．アロエも一緒に植えられていた．

伊豆半島の南端まで行ったので，帰りに河津町の桜の様子を見てきた．全体的にはまだまだ．一部咲いているところあり．原木も一部の枝で花が咲いていた：

まあ，元気があったらもう一回来よう．

閑話休題．

国道１３５の真鶴手前の案内板に「真鶴は左車線、東京は右車線」と行った具合に案内が書いてあった．東京へ帰りたかったので右車線に乗った．そしたら引き返せない有料道路（真鶴ブルーライン）に強制的に進入させられた．しかも料金所はETC使えないというイジメ．

嘘は言ってないが真実全てでないという詐欺情報に引っかかったわけだけど…　有料道路への案内に「有料」と明記して欲しい．更には，右に行っても左に行っても距離の差は殆ど無く後に合流して東京へ向かうのだから，せめて「東京への近道は右車線」といった表記にしておくべきだと思う（小田原厚木道路を見習え）．まあ，これらは有料ではあるが確かに信号もなく時間的に近道になっているから許す気にもなるのだけど，料金所がETC対応でないのにそういう事するのは腹がたつ．二輪でETCでない料金所通過するのは時間がかかって他の利用者への迷惑になるわけで．ETC付けないなら２輪を無料にしろ！と言いたい．

新しい計算機のテストを兼ねて nクイーン問題の並列プログラムを走らせた．対称性を使って枝刈りすれば単純に8倍くらいは速くなる気もするのだけど，面倒なので全探索で．探索木のルートから４段まではジョブを盗めるようにした古典的なワークスティーリングの実装．別にマスタ／ワーカでやりゃいいんだけど大分前に書いたテスト実装のプログラムを使い回し．

で，とりあえず21クイーンの解の数314666222712を得るのにすら225分もかかるという結果…

こんなもんなのだろうか？　手元の3台計28コアの結果だけど，この10倍くらいプロセッサを使いたい気分．学科の計算機がパッケージアップデート出来なくて使えないのが痛い．

閑話休題．

MPIも問題なく動くようになったし，これで新しいマシンの準備が整った．めでたし．

暇なので 22クイーンもやってみよう．

バイクが6ヶ月点検を終えて返ってきた．法令の定期点検は1年単位だけど，半年ごとにやっておかないと保証が消えるしオイル交換とチェーンの調整もしなければならなかったのでお願いした．工賃8400円＋オイル代（３０％引き）で12k円弱．ついでにバッテリーのテスト・充電とクラッチ調整とお掃除も付いてたので値段に文句無し．プラグやエアクリーナのチェックもあったっけね．

さて，今回はフィルタ交換しなかったので，次の点検時には交換を忘れない様にしとかんと．どうせまた結構な距離を走るだろうから．

MPICH2の話．単一マシン上での複数プロセスは問題ないのだけど，複数マシン間でのプロセス起動に失敗しやがってくれる．

うーん，mpd もブートに失敗しているのでマシンの設定が悪いんだろうなぁ…　微妙に configure のオプションとかも昔と変わってたのでもう少し勉強せんと思い通りの環境に並んか．

とりあえず -verbose オプション付けても何が悪いかよく分からない．

解決： /etc/hosts に使用する全マシンのIPを正しく書いておくと良い．

http://ubuntuforums.org/showthread.php?t=1616288 とかそこらの ML のログを見てたら同じような症状が /etc/hosts で解決できるっぽいことがわかったので試しにやってみたらちゃんと動いた，Hydra も mpd も両方とも．自身のIPをちゃんと取れていなかったのが問題なのかしら？　とりあえず動いたので良しとしよう．

動いた記念に3台使って20クイーン問題を頑張って計算させる．対称性とか気にしてない実装なので遅いけど新しいマシンの負荷テストということで．

２年前，いよかんの季節に「いよかんの皮のむき方」とかいうエントリを書いた．正しくは「いよかんの変な皮のむき方」だったりするのだけど…　

で，なにやら google で「いよかん 剥き方」を検索するとそのエントリが上位に現れるらしい．画像検索すると螺旋に剥かれたいよかんが最初の画面にひょっこり現れるし．こんな剥き方なんぞ全く世の中の役に立たんよなぁ…　子供は喜びそうだけど．もう少し気の利いた剥き方を開発したい気がする．

それはさておき，いよかんの正しい食べ方（皮のむき方）ってどんなんだろう？　いよかんの皮は中途半端な硬さなので手で剥こうと思えば剥けるけどみかんほど簡単じゃない．かといって包丁とか持ち出すのも大げさすぎて照れ隠しに螺旋に皮を向いてしまったりするし．今度愛媛の人間に聞いてみようかね．