研究で使用する Ruby プログラムが 自作ライブラリの幾つかに依存しているため インストールに手間がかかる。 私一人の問題なら常に何か適当にインストールしているので あまり問題はないが、 共同研究者に渡す場合は依存関係を正確に把握して 同梱する必要がある。 この辺の依存関係を解決するのに Gem にしてしまうのが良かろう。 公開しても良いプログラムだし。 で、gem 作成のための jeweler, github, rspec などについて勉強。 これまでテスト環境は Ruby 同梱の test/unit を使っていたけれど、 rspec, test-unit2 などが新しく出て来ている。 test/unit より相当便利になるらしいので調べてみた。 test-unit2 は従来の test/unit に後方互換性を保持しているので 移行が簡単そうだが、 jeweler との連携がうまくいってなさそう。 私の環境では jeweler --test-unit すると何かエラー吐きよる。 rspec は Test Driven Development というよりは Behaviour Driven Development という感じで思想が少し違う。 とりあえず利用者も多いようだし、 rspec に触れてみるのも悪くない。
計算が終わらん……。
Ubuntu 11.10 Desktop で 32 bit 環境を構築しようとしているが、 これも妙に遅い。
Gem を作成できるようになった。
テキスト編集時にタブ文字の使用をやめることにした。 jeweler で生成される Rakefile その他がやっぱり空白文字であり、 それに自分の環境がタブ文字だと混在することになってしまうので。
test/unit では assert メソッドで値の比較をする。 このとき引数は、期待した値、オブジェクト操作の順序で記述する。 これが頭の中で考える順序と逆になるため、 よく第2引数を書いてからカーソルを左に移動して第1引数を書いていた。 rspec ではこの順序が入れ替わり、 思考と同じ順序で書けるのが嬉しい。 また、test/unit だと基本的に 1つのテストケースクラスの 中でテストメソッドを用意という構造になっているが、 rspec は describe を複数用意できるので、 テストのおおまかな階層化・分類がしやすい。 (この点は test-unit2 では改善されたらしいけれど。)
計算管理ライブラリを作った。 それ以外は概ね過去の資産の Gem 化作業。 暫く rspec で戦ってみる事に決めたが、 かといって過去に test/unit で作ったテストを rspec に書き換えるのはやりすぎだ。
gem 便利だな。
ssh-agent。 随分昔にちょっと触ったこともあったがなんかよく分からんと やめてしまっていた。 ちょっと調べ直してパスフレーズを省略する方法を覚えた。
計算は少しずつ進んではいるが、遅い。 焦れる。
Debian で 64 bit 環境挑戦。 ネットワークがやたらと遅いのはオンボード NIC の Marvel が 原因な気がする。 そういや以前も同じトラブルに見舞われた気がする。
会議に 3時間。 同じ話を何度もループさせるなんて、皆我慢強いなあ。 議長スキルってのは稀有な能力なんだろう。 ともすれば発散しがちな発言を 議題に沿ってないものは打ち切って皆の時間を節約する。 それが簡単でないことも分かるが、そもそもその意識がない人が多い。 「同じ時間に同じ空間を共有することで連帯感を 作るために会議をやっている人がいる。 その目的を持つ人にとってはダラダラやることが悪ではない」。 これは同僚の指摘だが、成程と思う。 雪深い村社会ではそのような空気を醸成し易いというのがその人の説。
具体案を示さない発言をどうにかして欲しい。 「私はこう感じるんだけれど、何か対策を考えた方が良いのでは ないでしょうか？」とか。 じゃあどないすんねん。 具体案を誰かが出してくれるのを、 魚がやるように口を開けてじっと待ってるつもりなのだろうか。 現時点で一番問題意識を持っているのが自分だというのに。
これまでに作ったものの幾つかを Gem 化してみる。 パッケージ名の基本スタンスとして、 内容を簡潔に表す名前が良いのは言う間でもない。 しかし rubygems というのは世界中で共有された一つの名前空間な わけで、共有する人々の利益の最大化を図るために パッケージの名付けに少し思考が必要かと。 依存する要素は以下の2つ： 自分以外に同様のパッケージを作成しそうな人の数、 最終的に到達すると考えられる完成度。 たとえば代数ライブラリは自分以外にも多数によって作成されそうで、 自分の作るものはそれらと比肩しうるようなレベルにはならないだろう。 なのでこういうものに Algebra みたいな名前を付けてしまうと 他の人がもっと良い物を作ったときに自分の生成物が邪魔になりうる。 アナグラムなどでもじったような名前にすべきかもしれない。 しかし自分の作るものが最高水準になると信じているならば、 先行者の特権としてそういう名前を付けてみても良いだろう。
公開ソースコードもこれまで通り Subversion で管理したまま、 そのディレクトリを git でも管理しようとか思っていたが、 この方針はお互いの挙動を制御しあわなならんのでかなり面倒。 二重行政イクナイ。 ということで Gem 化したものなど Git で管理する奴は Subversion 管理から抜くことにした。
人によってやり方が違うということが当然のことで、 自分のやり方を確立している人に 自分のやり方を押し付けるとストレスになる。
ぬか喜び。 ぬーん。
ヨメと私が着替えしてるとか、 ふと姿が見えない瞬間があるとムスメが泣く。 親が出掛ける用意をしているのを見て (おそらく母親と離れる事を予期して)泣く。 私がムスメを連れて玄関に立ち、ヨメと別れるときに泣く。 託児所で私と別れるときに泣く。 大変だ。 まあ今迄が泣かなさすぎたのかもしれない。 がんばれ、ムスメ。
今のムスメと私の三大遊びは「ムーミンみる」、 「しょうぎのこま」、「あのほん」。 ムスメはムーミンの録画を見るのが好きで、 私が家にいると「ムーミンみる」といって一緒に見ることをねだる。 「しょうぎのこま」は将棋の駒を将棋盤に並べて遊ぶこと。 法則なく適当に並べて「これなに？」「ふ、だね」とか言う。 「『あ』のほん」は安野光雅の『あいうえおの本』。 隠れている動物とかを見つけて遊ぶ。 好みのページは「あ」のページの「ありくい」、 「い」のページの「いのしし」、 「か」のページの「かがみ」、 「け」のページの「けんだま」など。
Git の本を読む。 分散バージョン管理システムを考え出した人は本当賢い。
読書会。 私にとっては、横でやっている雑談の方をメインの目的として捉えてもいいかも。 本から直接得られる知識は一人で本を読むことでも得られるが、 参加者の言葉は他では得られない知識で、 様々な現場で活躍している技術者の生の言葉だ。
2つの手法の結果が異なるのが怖いから片方でしか研究しないという 考え方があるらしい。 それは科学者としてどうだろう。 むしろその差が生じればそれが何に起因するかを追究できるし、 そこが科学が進歩する最前線に相当すると私は思うのだが。
書類作業。
ムスメが社会と触れ、同年代の友達の作り方を知る為に 託児所は良い環境。 可能ならばもうちょい早い時点から入れたかったという気持ちもあるが、 ヨメが仕事してない状態で預けるのも経済的に厳しい面があったりと仕方なかろう。
書類作業。 これよりもコード書きたい。 これ済ませたらきっと俺はガンガン研究するんだ……。
文章仕事一段落。
感情が声に反映され、トーンが下がるのが俺の良くない点だなあ。 もっと上手に感情を隠蔽しないと。
家族が同じ時刻に食事を取るのに、それぞれ別のテーブルで食べる。 こういう状況に私は違和感を抱くが、 そういうのが気にならない人もいる。 友人が商店の家庭の育ちで、 それぞれが食べられる時に食べると言っていた。 それでも立派にしっかりした人格に育つということではあるが、 他の文化を知った後から考えれば窮屈だった、という感じらしい。 山岸涼子の巻末おまけ漫画のおはぎの話もそうだな。 まあ私はムスメの迎えがなかったら基本終電で そもそも晩御飯の時間が合わないという生活を送っているわけで、 そんな私に何か言う資格はないのかもしれん。
送り迎えを週のうち合計 6回(3往復)。 土曜日は半日子供の面倒を見る。 家にいる間は、できるだけ子供の相手をする。 夜の時間が使えなくなったのでヨメの職場復帰してから 仕事に割く時間がかなり減っている。 まあ元が異常な数字だったということもあるだろう。 自分では結構子育てに貢献しているつもりではある。 世間的な平均値がどの辺かもわからないことだし、 やって当然のラインなのかもしれない。 私はどっちにしてもやるから調べる必要もない。
git でソースコード管理する方針。 私の場合は自宅・職場・電車移動中の3箇所でコードをいじり、 中途半端で動かないなどのコミットすべきでない状態で 作業を中断することがよくある。 こういう状態のコードを公開リポジトリである github に push するのは憚られるため、 自分の私的な git リポジトリも必要になる。 調べてみると git は push 先に複数のリポジトリを設定できるので、 普段使いは自宅サバに、リリース時には github に、 とすることができそうだ。 この場合 origin をどちらにするか？ 意味的には自宅サバが主体で github はリリース用なので 自宅サバを origin にしたくなるが、 jeweler の rake release を利用するには origin は github に しておいた方が問題が少なさそう。
夕食の白米が苦痛。 なんかずしーんと気分が悪くなった。 肉体的な不具合かもしれないし、疲労とかを含めた精神的なものかもしれない。 とりあえず米の量を減らしてもらうようにお願いした。
ヨメが数日家を離れる時に炊飯器に白米が保温のまま 残っていることがある。 その保温白米は私にとってかなり嬉しくない状態に既になってしまっている。 マラソンに向けての減量以来、 私は米を食わんでも平気になってそもそもあまり米を食わない。 もし米を食うなら白米よりも玄米を食いたいし、 もし白米を食うならば 丸1日以上保温した米よりも、 炊き立てかすぐに冷凍保存したものを食いたい。 もし食わないという選択をした場合、 ヨメが帰ってくるまでの数日間保温し続けるのは電気代の無駄だ。 下手すると保存する米の価格よりも電気代の方が高くつく。 冷凍するとヨメにとっては嬉しくないらしく、私の弁当に回ってくる。 まあ「捨てるのは悪」という心理的な抵抗を無視して、 そういう保温白米飯は捨てるべきなんだろうなあ。 伝統的な食文化では腐ってない物を残飯として捨てることは悪だったが、 カロリー過多になりがちな現代では残さず食う方が 糖尿病などの観点から良くないとも言える。 食うという行為の根源的な目的は健康で活動的な肉体と精神を維持することだ。 食うことにストレスを感じたりカロリー以外の栄養に乏しいものを 無理に食う方が本来の目的から外れるとも言える。 米が残らないように上手に調整できるのがベストだが、 ムスメが食う量が不確定という問題があって中々難しいのだろう。 そういう意味でもヨメが冷凍飯を使いこなし、 ムスメに出すのに冷凍飯を使用できるとより便利になると思うが、 まあ難しいだろうな。 人間は自分が不味いと思うものを他人には出せないものだ。
私はまず米を食わんでも良い。 どうせ米を食うのならば玄米を食いたい。 玄米を食えないのならば、炊きたてか直後に冷凍したものを食いたい。 私にはそのための手間全てを払う用意がある。 けれども色々あってできないことになっている。 「米飯を半分にして欲しい」というのは 私から見れば 3段階の譲歩をした上で、 1段階の半分だけ戻ったところを妥協点として相談したつもり。 最初に最大限の望みを全て言って、そこから妥協点の交渉という 欧米式の交渉をせんとあかんのかもなあ。
私はムスメと食事の時間を合わせて食べたいと思っているが、 どうもヨメ的には手間などの問題からウェルカムじゃないらしい。 多分団欒に対する価値観の違いだな。
ヨメが起こすまで、私は毎朝起きていないと思われているらしいが、 実際は週に何度かは先に起きている。 しかし自分のことをごそごそする以外にすることがない。 冷蔵庫におかずの用意があっても、どれが朝食用のものか分からない ことが多い。 いつヨメが起きるか分からないので 何か食事の用意をしようとしても半端になりそうだ。 洗濯物干しはゴソゴソ音がして寝ている人を起こしてしまうので、 せめてヨメが起きるまではやらないようにしている。 だから部屋でコーヒーを飲んだりしながら何かしている。
subversion, git での変更をまとめて扱うスクリプトを作った。
たとえば運動部の先輩が理不尽だったとして、 自分が先輩になったときに後輩にどう接するか。 自分が受けたように横暴に振る舞う人と、 自分の代で断ち切って改善しようとする人とに おおよそ2種類に大別できそうだ。 社会人でも同じで、 自分が上司になったときに部下にどう接するかという問題になる。 自分が下積みの時代に無茶を言われたならば、 自分が上司になったときにどうするか？ 上司・社長になってしまえば無茶な命令しても良いのか、 それとも構成員が気持ち良く働ける環境を整えるのか。 「気にしなくても良い」というのは潜在的な暴君。 私は、上司はその組織の利益と幸福を最大化すべく心を払うべきで、 そのためには後者である方が有利だと思う。 理不尽な扱いを受けたこともあるし、 将来それに関わるポジションにも就きうるだろう。 その時、自分が受けた理不尽を行うまいと私は思う。
ムスメを迎えに行くと、 大抵ムスメが最後の1人。 たまに他に 2人いることがあるくらい。 今日は他の子に「なんでお母さんがこないの？」と聞かれた。 子供は実によくみてるなあ。 我が家はたまたまヨメより私の方が時間に都合を付けやすいので そうなっているが、 そうでない家庭の方が多いのだろうな。
ムスメは友達ができてきたようだ。 話の端々に他の子供と思しき名前が出てくる。
ヨメは早くに仕事に出た。 小雨がちだったのでムスメと散歩には出ず、 自宅と実家で遊ぶ。
ヨメが帰宅するまで元気一杯遊んで、 ヨメの顔を見て安心したかのようにコテンと寝た。 丸一日面倒見たのが久しぶりだったので、 昼寝するもんだということを忘れていた。
姉のゴルフ練習につきあう。 姉は自動車運転免許を持っているが運転をほとんどせず、 自分で運転するのが不安なので私に声がかかる。 打球はまあそこそこ。
「〜〜できなかったのか？」ではなく「〜〜しなかったのか？」と まず聞く人は、おそらく他人のことを信頼しておらず、 無意識にそれが出るのだろう。
「食事中にテレビを見るのはいけない」と私は躾けられた。 子供はシングルタスクで噛まなくなるということもあるが、 もう一つ理由が考えられる。 食事というのは自動的に家族が一箇所にいることになるので 団欒の場として優れている。 幼い頃の人格形成期に家族とのコミュニケーションは 多いほど良いが、 そこにテレビが入ると受動的に見ることばかりになって コミュニケーションが減ってしまいそうだ。 私はムスメと食べる時あまりテレビを見ないように意識しよう。 まあテレビも話題提供の機能があるので悪影響のみとは言えないが。
コンパイルが通らん。 Ruby のような高級言語ばっかりやってて、 C や Fortran のような比較的低級な言語と ライブラリのリンクとか、 コンパイラのオプションとかその辺の知識がなさすぎる。
ムスメの食事トレーニング中。 でもなかなか上手くいかない。 まあしゃあない。 子供だし強制させるわけにもいかない。 だが基本がそれだということは示し続けるべきだろう。
ムスメが泣くようになってきた。 いままではあまり泣かない良い子だったと言えるが、 手はかかるが子供らしくなって来て良い傾向とも言えるだろう。
コンパイルとかリンクとか勉強。 大分学んだ。 なかなか segmetation fault がなくなってくれないが、 とりあえずこの世界の泳ぎ方が分かってきた。 早くこの仕事終わらせて研究の方に入りたい。 まあコンパイルとかも計算屋やってる限りはいつかは使う技術の筈だ。
最近は i386 と amd64 混在環境になってきて、 LD_LIBRARY_PATH などの環境変数がゴチャゴチャしてきた。 PATH については自作の処理ルーチンで候補から存在するのだけを 登録していたが、zsh の typeset を使うとその辺が簡単にできる らしい。 ということで PATH も自作ルーチンを捨てて typeset を使って 書き変え、 LD_LIBRARY_PATH なども修正した。
古いコーヒー豆の消費の為もあって、 職場に着いてすぐ豆を挽いてコーヒーを淹れている。 コーヒーは飲むよりも淹れる方が楽しい。
コンパイル作業はもう一息感。 shared object の作り方を調べてみたり、 デバッグオプションを入れて gdb に食わせてみたり、 ldd, nm といったコマンドを知ったり 色々回り道はしているが大分原因箇所を特定できてきた。 今の segmetation fault は FFT まわりに原因がありそう。
食った物で気分が悪くなった。 この世から白米がなくなればいいのにとかちょっと思ったが、流石に思い直した。
朝、今から家族全員が出掛け、夜まで皆帰らないという時に炊飯スタート、 という衝撃的な場面を見た。 ヨメは、夜これから全員寝るという時でもスタートする。 「予約炊飯にしてくれると嬉しい」と言ってみたが、 「できてなかったら困るから」とのこと。 帰る時刻はそんなにバラついてないのでいけると思うんだけどな。 ムスメを連れた私の帰宅時刻は 19:40 ± 15分くらいで 安全係数として 30 分くらい見れば 99% くらいカバーできると思う。 仮に帰宅時刻のバラつきを含めたムスメに夕食を食わせる最も早い時刻が 18:00 だとすれば、17:50 くらいに炊けるようにすれば良いと私は思う。 何十時間保温しても味が落ちないという意見もあるらしいが、 より美味くなるという意見は聞いたことがない。 10:00 に炊き上がって 18:00 までの約 8 時間分、 電気の無駄遣いして味を落とすだけだと私は思うんだけどなあ。
一つ完全に動く状態にするというのはとても大事だな。 その状態からなら部品を一つずつ交換して いくことで原因箇所を特定し易い。
文書系データも git にした。 svn だとディレクトリいじってコンフリクトが生じたときが大変。 git は svn よりも文章書くのに向いていると思う点がある。 リポジトリを比較的簡単に作れて、 開発単位を小さく保てるということ。 Subversion でリポジトリを作ったのはもう随分昔にやっただけなので 随分忘れたが、 今 git でリポジトリを作るほどには単純ではなかった気がする。 慣れもあるだろうが、git でリポジトリを作るのは数分作業で、 一時的な文章のための小さなプロジェクトを簡単に作れる。 たとえば科研費の申請書とか、提出時期までに作ってそれから先は 一切いじることがないデータというのはこういう小プロジェクトに 向いている。 Subversion で既存のリポジトリのどこかに入れてしまうと その履歴ごと永続的に残るのが気持ち悪かった。 テキストだけだったら容量が少なくても良いが、 数 MB とかの画像が入る書類だとさらに気を使う。 こういう気を使わなければならない、というのが嫌。 小さなリポジトリを作って、 数週間それで運用し、提出して完成版をアーカイブしたら リポジトリ自体は削除して履歴データは抹消ということがやりやすい。
ファイル名やディレクトリ名の大幅改造があるとき コンフリクトが生じやすい。 git では直前までバージョン管理システムに伝える必要がなく、 最終的なものだけ git add すれば良い。
私が新歓コンパでムスメの迎えに行けないので 母(ムスメから見て祖母)にお願いした。
64bit 環境でのコンパイルが通り、segmentation fault なく プログラムが走った。 あー疲れた。 解決した問題点は、 Intel MKL の make がうまくいっていなかったこと、 対象のプログラムを ifort でコンパイルするには -heap-arrays オプションを付けないといけないこと。 まあ今回のおかげでライブラリ回りの扱いが結構分かった。 最終テストと HDD コピー準備の段階で時間切れ。 もうちょいやりたかったが、仕方ない。
公園に行ったらいつもより人が多い。 近くの会場から伸びている行列があったので、 何かイベントの待ち時間を使って 公園で子供と遊んでいる人が多いのだろう。 子供連れも妙に多いが、 子供を連れていない妙に若い女性もいる。 行列の最後に看板持ちがいた。 戦隊物のショーのようだ。 なるほど。
ムスメはドアを閉めたがる。 これはヨメの躾か、習慣の模倣だろう。 無駄にドアが開いているとせっかく暖房を入れていても寒い。 ドアを閉めるという行動を、親がしているのをよく見ているのだ。 特に義実家は大阪よりも寒いので、 ヨメはその辺徹底しているのだと思われる。
扉をキチンと閉めずに少し開けたままにしてしまうと 魑魅魍魎の通り道になるという民話がある。 これは「雷さまにヘソを取られる」と同様、 体を冷やして病気にならないように、という効果を持った 戒めだと思う。
姉が職場の同僚を呼んでホームパーティを開いたので、 色んな人がいる場にムスメを慣れさせるための場として 利用させてもらった。 以前はわんわん泣いたりしたが、 だいぶん慣れた感じ。 成長してるねー。 物怖じしない感じ、ではないが、その辺はまあ個性だろう。
とにかく寝まくった。 査読を進めようとも思ったのだが捗らず。
保育園の入園申し込みを区役所へ提出。
ランニング帰宅。 5500m を 45分。 足指がいたい。
保存食への加工でない限り、 一般に食材は調理したほうが日持ちが悪い。 だから「食材が痛むから料理してしまう」という方針は 正解でないことが多い。 食い切れなくて余る分は、 調理した方が調理しないよりも早く痛む。 人が食う量と速度には限りがあるわけで、 それを越えて作られた料理は腐る運命にある。 しかし腐ることは食べる人に責任があることではない。 調理せずに置いておいた方が長持ちするし、 腐ったとしても調理にかかったエネルギー・時間コストが 無駄にならない。 そもそも食材を痛ませないためには 痛む前に食える量を越えて買わないのが一番合理的で効果的。 勿論、買ったのではなく貰い物なら仕方ない面もあり、 誰も悪くないということもありうる。
趣味だったらどんなに忙しくても出来る、 という人は本当にいるのだろうか？ 普通、仕事や生活で使った時間の余り時間の兼ね合いや、 趣味同士の時間のやりくりでその趣味にかける時間が変わる。 また、料理好きを自負する人でもカップ麺を食べても良いだろう。 あれはたまに非常に恋しくなる。
「〜〜しなくても良い」ではなく、 「〜〜してはいけない」と言う人がいる。 しかし細かいことを気にせず 「〜〜しないようにする」くらいに脳内翻訳すべきなんだろう。 命令にしてしまうとそれに沿わない行動をされた場合は問題になり、 嫌な気分になりそうだ。 「〜して欲しい」と言うようにすれば世界の見方がもうすこし優しくなると思う。 なお、ミスってもたかが数百円オーダーの損失の事に私は 「〜〜してはいけない」とは言わない。 話し合いを無視しない、というのは私がする数少ない命令。 これは話し合いができなければ人間関係、すなわちコミュニティが崩壊するという危機感を 持っているから。 それが職場、家庭いずれであっても大変困ったことになり、 数万倍レベルに桁違いの損失となりうる。
正確に、平等に紹介してなければ希望者が少ないというのも 当たり前のこと。 不平等な状況を作っておいて、 人が希望しないのだからこういう風にする、とかいう論法は卑怯。 せめて公平な仕組みで行ってから言うべき。
ムスメ「あかんの」。 ムスメにとってムーミンの季節が終わった。 ムーミンよりもポンキッキとかの絵つきの歌が良いらしい。
ムスメ「たしかにまどあるね」。 確かに私は「確かに」をよく言う。
ムスメの「これなに？」は「食べてもいいか？」であることが多い。 また「キティちゃん」は 「キティちゃんの水筒に入っているお茶を飲みたい」だ。 「『たべたい』『のみたい』の方が分かり易いよ」と 言ってみてはいるのだが、 なかなか覚えてくれない。
味覚は人それぞれ。 玄米食べると気分が悪くなる人もきっといるのだろうなあ。
日食サングラスにはフロッピーディスクがいいと以前まさひろから 聞いていたのを思い出したので家を探すとすぐに見つかった。 ハンズフリーで見れるようにメガネ型に工作しておこう。 5/21 の日食は朝 7:00 台のことらしいので 仕事とも干渉せず観察できる。 我が家は北東向きで昼間は太陽が差さないが、 朝の観察はバッチリできそう。 実家の人も誘ってみるかな。
三大珍味の一つのトリの脂肪肝の奴の名前を思い出そうとして 「フェラガモ」という音が頭に響いた。
価格が高ければ品質が高いというわけではない。 両方試してみて初めてどちらの品質が高いかが分かる。
命令者は自らの行動によってその範を示さねばならないし、 自らが下した命令によって観測結果が歪むことも考慮しておかねばならない。
問題点に集中して話すればすぐ終わる議題なのに、 自分が責められていると誤解して逃げ回るから いつまで経っても話が終わらない。 「話が拡散して終わらない」と相手を責める人の中には、 自分自身がその拡散源になっていることに気付いてないだけという人が一定数いる。
書類が1個欠けていた……。 2ページなので1日で書けるとは思うが。
ムスメとお留守番。
『よ坊さん』という予防歯科のゆるキャラアニメがムスメのツボに 入ったようだ。 あと『おばけのホットケーキ』。 ムスメは見たがるものが目まぐるしく変化する。 昨日、先刻見たがったものが、 今もう「これあかんね」、「がちゃんする」。
ムスメと公園でボール遊び。 ムスメの方に軽くバウンドさせて投げるのだが、 ボールのベクトルでどこで追い付くかの予測がまだできていない。 現時点の座標のみを見て追い掛けてる感じ。
人形 2体の一方をムスメが、他方を私が手に持った。 次にムスメが言ったのは、「はっけよーい、のこったのこった」。 ムスメは持っていた人形で倒れたような動作をして、 ムスメ「しんじゃった」。 私「えーっ！おすもうさん死んでないよ！」。 『よつばと』を見ているようだった。
ヨメにムスメを任せて職場へ。 厳守締切の書類がまだ。 9割方完成というところで帰宅。 明日も職場だな。
査読もまだできていない。 今後、どんだけ分野が違って分からないと思っても、 査読を断らないようにしよう。 勉強になる。 責任がある仕事ではあるが、 そもそも不適格者に査読を依頼する側の責任の方が大きい筈だ。
ムスメがヨーグルトをもりもり食う。 3杯目は砂糖を減らしたら少し残した。 うん、砂糖の量で食う量をなんぼか調整できそうだな。
ムスメの「おとーしゃん」は「おとうさん」に進化しそうな 感じだったが、 たまに「おとーちゃん」と発音する。 うんうん、どっちでもいいよー。 年頃になっても「おとうちゃん」と言うムスメを想像して ニヤニヤする。
すべり台を滑る。 「あと3かい」という言葉を覚えたようだが、 「あと4かい」、 「あと5かい」。 滑る度に回数が増える！不思議！
午後は職場で書類仕事。 私が持つありったけの国語力をぶつけた感じ。 もう少しだが、終わらなかった。 とりあえず帰宅するが、今日は睡眠時間の削り時だな。
最新日記の各日付が当該月の日記へのリンクになっています。 さらに過去のものはトップページから辿れます。