目次
2020-02-28 なんというか…
2020-02-27 BABA IS YOU
2020-02-22 node-tyrant のバグ修正
2020-02-16 MacBook Pro 購入
2020-02-15 バレンタインの直前に
2020-02-03 台風被害の修復完了
2020-01-31 風邪ひいた
今月の日記
多くは言わない。
９年も前に書いた日記へリンクしておこう。
インフォデミック、という造語は、言い得て妙だと思うよ。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
中３の長男の受験は、先週中に終了した。
そこで、以前から僕が欲しかったゲームをやっと購入できた。
僕が遊んでいたら長男も気になるだろうし、受験終わるまで待ってたの。
BABA IS YOU。
１年くらい前に PC で発売されたゲームで、その時から興味を持っていた。
昨年末には Nintendo Switch で日本語版が出たので遊びたかったのだが、上に書いたような理由で我慢していた。
興味は持っていたのだが、基本ルール以外の情報があまり入ってこない。
というのも、これはパズルゲームであり、詳細を伝えるとネタバレになる恐れがあるためだ。
ここでも、読んでいる人が興味を持てるかどうかのぎりぎりの情報しか出さないようにしよう。
ネタバレすると困るから。
基本的には、倉庫番タイプのゲームだ。
主人公はマス目の中を動く。
障害物には、動くものと動かないものがある。
動くものは押せる。動くものの向こうに動かないものがあると、押せない。
倉庫番の場合、動くもの（荷物）が２つになっても押せなかった。
BABA IS YOU では、いくつでもいっぺんに押せる。
ところで、以前に僕はゲームに関する持論を書いたことがある。
ゲームのルールは、シンプルでなくてはならない。
しかし、状況は十分に複雑でなくてはならない。
ルールを複雑にすれば、当然状況も複雑になる。
しかし、それではルールに振り回されるだけで、楽しくないのだ。
すぐに把握できるほどシンプルで、それを駆使して複雑な状況を乗り切るのが楽しいのだ。
「倉庫番」は、過去に書いた日記でも、シンプルで複雑なゲームの代表として書いた。
しかし、BABA IS YOU は、シンプルといってよいのかどうかわからないんだ。
ルールはすぐに把握できる。上に書いたように、倉庫番と類似だ。
しかし、BABA IS YOU の特徴は、このルールの中で「追加ルール」を、ユーザーが自分で決められることなんだ。
最初の面はチュートリアルだ。
壁に区切られた、３マス分しかない細い通路と、主人公と思われる白い謎生物。
通路の途中には、道を塞ぐように岩が３つ並んでいる。
そして、岩の向こうには旗が立っていて、きらきらとしたアニメーションをしている。
倉庫番のように、通路を進んで岩を動かし、旗まで行くと「おめでとうございます」と画面に表示され、面クリアだ。
さて、面クリアしたら、もう一度同じ面を遊んでみよう。
通路の外には、単語が書かれたブロックが並んでいる。
４カ所にまとまっていて、それぞれは３つのブロックが組み合わさっている。
書かれているのは、次の通りだ。
BABA IS YOU
WALL IS STOP
ROCK IS PUSH
FLAG IS WIN
通路の外に主人公を動かして、これらの単語を押すと、動かせる。
例えば、 BABA IS YOU を動かして、並びを壊してしまうと…
あれ、主人公が操作できなくなる。しばらく待つと、画面上に「やりなおし 一手戻る」と操作表示が出る。
つまりは、失敗してゲームオーバーのようだ。
BABA とは「主人公」だと思い込んでいた、白い謎生物のことのようだ。
それが「YOU」、つまり主人公である、と示している。
そして、この「追加ルール」を壊してしまうと、主人公がいなくなるためゲームオーバーとなる。
WALL IS STOP を壊せば、壁はすり抜け可能となる。もはや、ただの背景だ。
組み換えも可能で、ROCK IS WIN にすると、岩がきらきらし始め、そこに行くと「おめでとうございます」となる。
さらには、WALL IS ROCK とすれば、画面上の壁がすべて岩に変わる。
単語は、縦に並べてもいい。
ただし、左から右、または上から下に解釈される。逆順にはならない。
ROCK
BABA IS YOU
PUSH
と並べると、IS を共有して、２つのルールが完成する。
こうやって「単語を節約する」必要があることも多い。
ちなみに
WALL
IS
BABA IS YOU
のようにすると、画面上の WALL が全部 BABA になって、キー操作で同時に動く。
WALL
IS
BABA IS YOU
だと、WALL がそのまま「主人公」に追加される。
BABA にはならないが、キーで同時に動く点は同じだ。
画面上のものがたくさん同時に動くのは、結構カオス。
見た目だけでなく、繊細な操作を必要とされるパズルゲームで、数の暴力を展開すると恐ろしいことになる。
（それが必要な面だってある）
DOOR IS SHUT AND STOP
KEY IS OPEN AND PUSH
とか書かれていたとする。（実際、これは多いルールだ）
ドアは閉まっていて、障害物。
鍵は開いて、押せる。
ここで、OPEN に対応するのが SHUT だ。
鍵を押してドアにもっていくと、開く。この時、ドアと鍵が同時に消滅する。
一方で、
WATER IS SINK
というのもある。「水は沈む」だ。
この場合、水に入ったものはなんでも消えてしまうが、同時に水も消える。
SHUT と OPEN は２つでセットだが、SINK は相手を選ばない。
しかし、「２つセットにすると消えてしまう」という現象は同じだ。
ここではさらっとルールを書いてしまったが、ゲームをしていて説明されることはない。
新しい単語を見かけたら、それがどういう意味か、実験しながら推察していくしかないんだ。
このゲームの面白さの多くの部分が、そうした「実験と推察」だ。
倉庫番のようなルールだけど、じっくり考えてわかるものでもない。
知らない仕掛けが次々登場して、その仕掛けの意味を調べつくし、それらをどう組み合わせれば目的を達成できるのか考える。
倉庫番なので、壁の角に押し付けられたブロックは動かせない。
ゲーム内では、これを利用して「変えられないルール」を作り出していることも多い。
もっと言えば、入り込めない壁の奥に書かれているルールは、不可侵だ。
変えられないだけでなく、その単語を利用することすらできない。
その一方で、壁に囲まれていて不可侵に見えるブロックを、「壁」自体の定義を作り変えて入り込んで利用する…というような面もある。
とにかく自由すぎる。
そして、自由かと思っていたら、どうしようもなく組み替えられないルールに悩まされ、不自由を感じたりする。
不思議極まりないゲームだ。
これは、一種の「プログラムゲーム」なのだと思う。
プログラムゲームとは、一定のアルゴリズムなどを記述することで遊ぶタイプのゲームだ。
戦闘アルゴリズムを書いて対戦する、なんてのが多いけど、ヒューマン・リソース・マシーンみたいな課題クリア型もある。
BABA IS YOU では、長いプログラムを組めるわけではない。
しかし、ゲーム内の文法に従って「記述」を行うことで問題を解決するし、その「記述」を複数組み合わせることで効果を持つ。
十分にプログラムだと言ってよいだろう。
購入前は、ルールを自分で変えられてしまうというので、比較的緩く遊べるパズルゲームを想像していた。
しかし、思っていた以上に難易度は高めだ。
その原因の一つは、新たな効果を持つ単語が出現した時に、その作用を十分に理解しないといけない、という点がある。
このゲームのルールが、シンプルといってよいのかどうか、最初に迷っていたのもその点だ。
基本ルールは非常にシンプルでありながら、単語の組み合わせ方は非常に幅広く、その効果も複雑だ。
この複雑さは、プログラムの複雑さと同じだろう。時にはバグも発生し、デバッグに悩まされる。
場合によっては、効果だけでなく、「効果による副作用」まで理解しないといけない。
そして、それらに対する説明は、どこにもない。
自分で実験しながら探し出さないといけない。
いわゆる「パズルゲーム」の難しさにとどまらず、「なにかを研究する」難しさに近いといってよいだろう。
先週末に購入し、長男が熱中して遊んでいるので僕はなかなか遊べず、まだあまり先の面を見ていない。
先の面を見るのが楽しみだ。
じっくりと考えることが好きな人には、自信をもってオススメできる作品。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、プログラマ向けのちょっとした推理小説。
まぁ、実際に今週体験したことなのだけど。
世の中には多くのデータベースソフトがあるが、SQL とそうでないものに大別される。
そして、「そうでないもの」の中に、key value store と呼ばれる種別のデータベースがある。
ざっくりと違いを書くと、SQL は多機能だが、高速ではない。
key value store は非常に貧弱な機能しかないが、無茶苦茶高速だ。
SQL ってのは多機能なので作るのが大変で、昔は高価なソフトしかなかった。
それが、PostgreSQL と MySQL の台頭で、無料でも使えるようになり、普及した。
ちょうど WEB の黎明と重なり、最初は重宝された。
しかし、WEB が当たり前の社会インフラになると、１秒で何千というページアクセスを支える必要があり、より高速な DB が求められ始めた。
そこに登場したのが key value store だ。
memcached というソフトが最初のきっかけとだったと考えていい。
現在人気があるのは、Redis だと思う。
Tokyo Cabinet は国産の key value store で、10 年くらい前に人気があった。
本当に機能が少なく、ネットワークにも対応していない。
これをネットワーク対応にする後付けのソフトが Tokyo Tyrant だ。
ちなみに「Cabinet」は、書棚などの意味。データを保管する場所だな。
しかし、英語では「内閣」などの意味もある。政治の中枢を担う組織。
そして、Tyrant は「暴君」の意味だ。
Cabinet を意のままに操るもの。面白い名前だと思う。
さて、現在お手伝いしている仕事のプログラムで、Tokyo Tyrant (以下 TT と表記）を使用していた。
以前は PHP で扱っていたらしいのだが、プログラムを完全に作り直していて、Javascript (node.js) ベースになっている。
移植は僕がやったわけではなく、他の方の作業によるもの。
ここで、完全に一から作るのは大変なので、フリーのライブラリを利用したらしい。
…というわけで探してみたら、これだな。
開発開始から半年以上たつが、特に問題なく使っていた。
先週頭くらいに、僕が新機能を実装していたところ、なぜかサーバー (node.js) が停止する、というバグに見舞われた。
まぁ、自分がプログラムを作っていてバグが出るのだから、自分が悪いのだろうと思って調査を開始する。
プログラムは、とあるきっかけでデータベースのフラグを操作するものだった。
もともと「ボタンを押したとき」に処理をするプログラムが存在したのだ。
しかし、新たに「設定時刻が来たとき」に処理する機能を追加した。
ところが、ボタンを押したときは正常に動作するのに、設定時刻が来たときにエラー停止する。
設定時刻が来た、というのは、cron などの意味ではない。
それでは、せいぜい１分単位の処理で、ユーザー操作とかみ合わない場合があるからだ。
ユーザーが見たときに、設定時刻が来たのであれば、その瞬間に画面に反映されている必要があった。
なので、画面を作るときに、データに記録された時刻を見て、期限を過ぎていたらフラグを操作する。
同じ処理関数を呼んでいるだけなのに、この処理をするとサーバーが停止する。
cron だと、動作するときにユーザー権限が違っていて不具合を起こすようなことがあるが、今回の話はそうではない。ユーザー権限の問題ではない。
じゃぁ、何が問題なのか。問題の切り分け作業に入る。
調査は難航したが、最後に分かったのはこういうことだ。
ボタンを押したときは、ユーザーのアクションを伴うため、フラグが変わった後にページ全体のデータをリロードしていた。
しかし、時刻が来た場合は、サーバー側でフラグ操作するため、必要なデータを書き換えるだけでリロードは起こっていなかった。
そして、「リロードすれば問題ないが、リロードしないと停止する」のだった。
ここで、先に書いた node-tyrant のライブラリだが、さらに改造して使用していた、ということを書いておく。
改造は多岐にわたるが、そのうち一つに「TT からの反応がない場合は、サーバー異常と見なしてサーバーを再起動させる」というものがあった。
サーバー停止は、この機能が働くためだった。
（実際は、停止するとサーバー監視サーバーによって再起動される）
ここで、TT との通信についても触れる必要がある。
TT には、コマンドを送ると、返答が返ってくる。
データはバイナリストリームで、基本的にはデータ長とデータがセットになった chunk 構造だ。
ただし、内部構造はコマンド毎に多少異なる。
バイナリストリームなので、「改行で終了」とかではない。
データ長を信じて処理することになる。
もう一つ、Javascript としての処理の方法を書いておく必要がある。
データはバイナリなので、改行で終了ではないと書いた。
入ってくるデータを常に監視しておく必要があるが、 Javascript では「常に監視」というようなプログラムは書けない。
そこで、EventListenr を使う。何かあったら関数を呼び出して、とシステムに依頼する方法だ。
TT との通信では、「データを受信したら呼び出す」関数を指定しておく。
ところで、ネットワーク越しのシステムなので、リクエストコマンドと返信データの間にはタイムラグが発生する。
そこで、リクエスト時にコマンドをキューに入れておき、データが戻った時はキューを見て処理方法を判断する。
先に書いたがデータ構造はコマンド毎に異なるため、こうしないと処理方法がわからないのだ。
ここで、データが改行区切りなどではない、ということに気をつけないといけない。
Javascript は「何らかの方法で」データが一区切りした、と考えて関数に渡す。
しかし、この区切りが何であるかはよくわからない。
データが途中で切れる、ということはなさそうだが、複数のデータをまとめて受信することはあり得るようだ。
断片的な話が続いて申し訳ないが、必要なことなのでもう少し続ける。
先に「TTからの反応がない時はエラー終了」するようにしてあった、と書いたが、この「反応がない」の定義が重要だ。
上に書いたように、TTへのリクエスト時にキューが積まれ、データが来たときにキューが消費される。
そこで、「最後のリクエストから３秒立ってもキューが解消していないとき」は、TTの反応がなかったとみなされるようになっていた。
TTは高速を売りにするデータベースなので、３秒というのはあり得ないくらい長い時間だ。
そんなに時間が空いたら異常と見なす、というのは、別に悪くないだろう。
さて、「リロードしないとエラー停止」は、この「キューの積み残し」が原因だった。
何らかの原因で、TTが処理できていない、と見なされるのだ。
しかし、エラー停止した直後にDBを確認しても、正しく記録はされていた。
DBからの返事がないだけで、動作はしているのだ。
さらに調べると、返事があるにも関わらずに受け取れていない、と判明した。
この「受け取れていない」は、Javascript が受け取れていないのではなかった。
Javascript が受け取っているにもかかわらず、「プログラムが」取りこぼすのだ。
なぜ取りこぼすのか調べる必要があった。
どんなコマンドを発行して、どんな返事が返ってくるかを調査する。
put コマンド（データの保存を意味する）を送った時、返事が 5byte …「正常終了コード」 1byte と、4byte (32bit) の「0」だとわかった。
これをプログラムが取りこぼす。
プログラムの流れを追いかけると…
先に示したライブラリを、読める人は読んでみるといい。
最終的に、コマンドの結果は 232 行目からの responseMisc で扱っている。
この中で、
if (data.length<9) return [null, -1, null];
という行があった。これは「9バイト未満のデータは扱えないものとして保留させる」指示だ。
５バイトが返ってくるにも関わらず、９バイト未満を認めない。
バグの原因は、どうやらこれらしかった。
しかし、ここで修正を加えるのは早計だ。
こんな単純なバグであれば、「必ず」バグが出て、プログラムがまともに動かないはずなのだ。
にもかかわらず、プログラムは通常動いていて、むしろ停止することの方が少ない。
何かがあるはずだ。
「保留させる」処理の後を考えてみる。
保留は本当に保留で、データを処理しないし、キューも処理しない。
そして、次のデータが来たとき、残っていたデータに「追加」されて、データ処理を再開する。
すると、データが「追記」されたために、データのサイズが増えている。
今度は９バイト以上になっている場合、処理が続行されて、正常な処理になる。
なるほど。普段は問題が出なかった理由が分かった。
先に、「処理の後、データのリロードをしている場合は問題がない」と示したが、追加データがあると処理がうまくいくのだった。
ここまで分かったところで、僕は一旦発注元の会社に報告をした。
自分のプログラムのバグだと思って確認していたが、データベースを扱うプログラムにバグがある。
これは大問題なので、プログラムの作者（古い PHP プログラムを移植した担当者）に連絡が行く。
彼なら TT のハンドリングがわかると思ったからだ。
しかし、彼はライブラリを見つけてきて、目的に合わせて少し改造しただけだという。
すでにある程度ライブラリを調査している僕の方がよほど理解していそうだった。
この時点ですでに僕の仕事は遅れ気味だった。
どうしても取れないバグで悩んでいて、さんざん調査してここまでたどり着いたところだったのだから。
だから、上からの指示は「僕はこの問題を離れ、本来のプログラムの作成に戻ること」だった。
しかし、この問題が解決しないと、プログラムのバグは取れない。
まぁ、「バグは僕のせいではない」ことにして、溜まっている他の個所の作業に取り掛かった。
しかし、他の人の調査報告を横目で見ながら、気になることがあれば手早くできる範囲で調査を続けた。
そもそも９バイト未満のデータを認めない、という処理に妥当性があるのか。
Tokyo Tyrant のプロトコルを調査する。
…少し古いものしか見つからなかった。
ここに、put の返答は処理コード１バイトのみ、と書いてある。
0 なら成功、それ以外ならエラーだ。
しかし、確認するとどうも５バイト返ってきている。
何がどうなっているのか。
プロトコル表あったよー、という返事だけしておく。
TT の現在のバージョンでプロトコルが変化している可能性もある。
うん、きっとそうだ。
別の人が、直接 TT を操作するプログラムを書いてみた。
put コマンドでデータを送り込むと、結果は 1byte が返ってくる、ということだった。
プロトコルのバージョンが違うのでは、という予想は違うことになる。
むしろ、なんで Javascript だと５バイトを受け取るんだ？
再びプロトコル表を見て、気になる。
今まで「返事」のプロトコルばかり気にしていた。put の送信プロトコルは正しいのか？
プロトコル表には、put に対するバイナリコードが書かれている。
プログラム内からこのコードを探す。たしか、先頭付近でバイナリコードの定義が行われていたはず。
// List of Command hex codes for Tyrant
var commandCode = {
misc: String.fromCharCode(0x90),
get: String.fromCharCode(0x30),
out: String.fromCharCode(0x20),
vsiz: String.fromCharCode(0x38),
iterinit: String.fromCharCode(0x50),
iternext: String.fromCharCode(0x51),
status: String.fromCharCode(0x88),
addint: String.fromCharCode(0x60),
}
…愕然とした。「put」のコードは、書かれていなかった。
しかし、node-tyrant で put コマンドを呼び出したときに、処理しているプログラムはある。
この処理関数を読んで、やっと気づいた。
node-tyrant のプログラムでは、put コマンドを送るために、put コマンドを使っていない。
TT には misc （それ以外）というコマンドがあり、このコマンドを経由して「隠しコマンド」が呼び出せる。
node-tyrant の put は、misc 経由で呼び出される、隠しコマンドとしての put だった。
こうなると、返答データも put と違って当然だ。
プロトコル表に、ちゃんと misc の返答プロトコルが書いてある。
[code:1][rnum:4][{[esiz:4][ebuf:*]}:*]
問題は、この表記方法は作者が定めただけのもので、特に意味は説明されていないことだな。
しかし、コマンド毎に返信データの形式が書かれているので、読んでいるとなんとなく意味が分かる。
[ ] はデータを意味していて、:n はバイト数のようだ。
ここには書かれていないが、省略可能な場合は ( ) で括られる。
複数回繰り返す場合は { } で括られる。
つまり、こういうことだ。
先頭に、処理コード１バイト（0 は成功、それ以外は失敗）
続いて、データ長が４バイト。
さらに、文字列長が４バイト。
文字列が不定バイト。
最後の２行は、セットになっていてデータ長の数だけ続く。
返事を処理する関数での制限、「９バイト」というのは、文字列長までは入っているだろう、という前提のものだったようだ。
後半が ( ) ではないので、省略されることはない、と考えたのだろう。
しかし、{ }:* という書き方が「０回以上の繰り返し」を意味しているようだ。
( ) で括っていないにもかかわらず、０回の場合は消滅する。
つまり、返答データが５バイトの場合がある。
（先に書いたように、間違っていてもなんとなく動くプログラムになっているので、作者が間違いに気づかなかったのだろう）
そういうわけで、最終的にプログラムは一カ所、1byte だけ書き換えられた。
「9」を「5」にしたのだ。これで動作して、安定している。
僕は、ここでの「長さ制限」自体が不要だ、と主張した。
データはバイナリ列のストリームで、「最後までの長さ」という概念がないはずだ。
にもかかわらず、長さで制限するのがおかしい。
実際、そんなおかしな前提だから、「次のデータがくっついたら動作する」などという、曖昧な処理になってしまうんだ。
しかし、データベースのインターフェイスは重要な根幹部分だ。
変更はできるだけ最小限が望ましい、というのが、発注元のプログラマの主張だった。
まぁ、その言い分もものすごくよくわかる。
1byte の変更で問題が解消する、というのは、最善の落としどころだろう。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
仕事のために「しかたなく」MacBook Pro を購入しました。
あまり使う予定がないので、一番安いやつ。それでも、税込みで１５万円ほど。
僕が今使っているメインマシンより高いんですけど…
以前は、携帯電話やスマホ向けの WEB ページを作る仕事が多かった。
特定機種で動作がおかしい、という報告があった時も、クライアント側で該当機種を貸してくれて、動作確認して修正、ということが多かった。
だって、機種が多すぎるから、報告があるたびにいちいち買ってられないもの。
しかし、今受けている仕事は、「通常の」WEB サービスだ。
動作保証は、 Windows の IE11 / Edge / FF / Chrome と Macintosh の FF / Chrome / Safari で行わないといけないことになっている。
機種でいえば「２機種」でよい。
そして、さすがに２機種だとクライアントが貸してくれることもなく、自分で買うことになった。
特に重要なのは、Windows で動作確認できない Safari なのだ。
で、さっそく以前から問題になっていた「Mac でのみ起こる表示崩れ」を調べた。
Mac だと Safari だけでなく FF でも起こる、と報告を受けていたので、フォントの問題なのだろうなぁ、とは予想していた。
思った通り、フォントの問題だった。
Safari の開発者機能を使い、CSS の font-family をリアルタイムに書き換えてみる。
そして、表示崩れを起こさないものを確認し、CSS ファイルを書き換える。
これで問題は解消した。
所要時間は 30分ほど。
とりあえず、今回購入した目的は果たした。
これだけのために１５万円ですよ・・・
（まぁ、今後も必要だろうから買ったのだけど）
同じテーマの日記(最近の一覧)
別年同日の日記
18年 Harley-Davidson & L.A. Riders
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
タイトル通り、数日前の話。
現在、非常に忙しい。
仕事は2月中締め切りなのだが、正直なところ間に合わない。
発注主もある程度認識していて、絶対間に合わせないといけない作業と、多少遅れても構わない作業を分離してくれているのだけど、その一方で「来週までにこの部分はお願い」なんて話も来る。
（関連会社に新機能をプレゼンする必要が出たりするのだ）
で、そんな忙しい状況の中でも、子供はバレンタインにチョコレートを手作りしたいのだ。
小６の長女、小４の次女は、お菓子作りを楽しみたい。
そして、毎年恒例で、その指導は僕がやらないといけない。
2月11日の建国記念日に、長女のお菓子作りの手伝いをする。
長女はクッキーが作りたい。
２年前に、猫の形のクッキー型を自分のお小遣いで購入した。
「友達が三毛猫飼っているから」と、クッキー生地をまだらにして、三毛猫を作って友人一堂に配ったところ、かわいいと人気があった。
昨年も作ったが、改良してより良い色が出るようにした。
そして、今年も同じものを作りたいという。
僕は朝から仕事をしていたが、午後になってクッキーづくりを始めたら、途中で仕事の電話がかかってきた。
ちょうど生地を練り上げて冷蔵庫で休ませるタイミングだったので、作業は中断。
…相談された作業を済ませたら、1時間くらいかかっていた。
生地を休ませるのは30分でいいのだが、冷やしすぎて固くなった。
子供に伸ばさせたら、固いので時間がかかり、もたもた作業していることで型抜きの時点で柔らかくなりすぎた。
一度麺棒に生地を巻き付け、再び冷蔵庫で冷やす。
…なんだかんだあったが、クッキー作業は無事終了。
先ほどの電話かかってきた仕事、ひとまず形にして終了したが、まだ続けないといけない。
次女のお菓子も作りたいが、この日はここで終了。
（クッキーは冷凍できるので、完成後冷凍庫へ入れた）
翌日12日。
平日なので当然普通に仕事をしているのだが、次女のお菓子作りをする。
チョコレートケーキを作りたいという。
こちらも、仕事とお菓子作りを並行して進める。
…少し置かないといけない時間などがあると、30分仕事を挟む、というような感じ。
子供が学校から帰宅した４時ごろに作業をはじめ、焼き作業は６時前。
長男を塾に送らないといけないので、焼き上げ作業を待ちながら夕ご飯を作る。
そして、ひとまず長男を車で塾に送る。
…焼きあがって、粗熱が取れたケーキを試食。
配りたい人数を考えると、小さいよな。もう一本作ろう。
そこから急遽、同じ作業を繰り返す。
１度目で作業概要はわかったので、２度目は早い。
７時半ごろに作業開始し、９時には焼き上がり。
すぐに長男を塾に迎えに行く。（塾は７時から、９時４０分まで）
チョコレートが入っているがパウンドケーキなので、焼き上げてから室温で１日ほどなじませる方がおいしい。
衛生面を考え、紙袋に入れておいておく。
よく１３日は、これらのお菓子の小分け作業。
長女のクッキー、次女のケーキを、それぞれミックスして友達に渡すそうだ。
せっかく違うお菓子を作ったのだから、そちらの方がバラエティがあって楽しいだろう。
この日も長男の塾があったので、長男が出ている間にすべての作業を終わらせる。
最近、長女・次女も夜更かし傾向になってきているのだが、この日は早く寝なくてはならない。
夜更かしすると、長男はさらに寝るのが遅い傾向にあるから。
で、昨日のバレンタイン当日。
僕はいつもより３０分早く、５時前に起きる。
長男の公立高校受験日だ。
朝ご飯とお弁当を作り、６時には長男を起こして朝ご飯を食べさせ、７時には家を出て車で駅まで送る。
もちろん合否はまだ出ていない。
というか、試験は３日間に分かれているので、まだ試験が終わってすらいない。
でも、１日目の結果は、自己採点によれば結構よくできていたようだ。
（試験帰りに塾により、先生と一緒に自己採点した。）
今年は、大学入試テスト改革の混乱を受けて、高校入試も混乱している。
具体的に言うと、例年と倍率の傾向が全然違うのだ。
長男が受けた高校も、例年よりも倍率が高い。例年だったら合格ライン、という点数が、全く読めない。
しかし、十分に実力を出し切ったらそれでいい。
「緊張して実力が出せなかった」だと悔いが残るが、実力を出した後の結果なら受け入れるしかないから。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
昨年秋の台風で、家に被害が出た。
一階ウッドデッキの上に付けたパーゴラが倒れ、ウッドデッキと隣の雨樋が破壊され、パーゴラ上にあった藤の木が隣家の水田に落ちる、という被害。
被害額は 100万円をこえるのだが、さいわいなことに保険がおりた。
「藤の木は家の設備ではないので保証しかねる」とのことで、藤の木を立て直す代金（作業代で２万程度だったかな…）が認められなかっただけで、ほぼ全額。
ウッドデッキは比較的速やかに修復してもらえた。
この際、本来保険では「原状復帰」が求められるのだけど、改良してもらった。
といっても、家との接続部分を少し変え、より動きにくいようにしただけ。
金額はほとんど変わらないので、保険的にも問題はないだろう。
雨樋は、パーゴラが倒れるのに巻き込まれて竪樋が壊されたのだけど、その力で 2階屋根の樋が壊れてしまった。
そうなると、2階部分を全部交換しないといけない。
その作業のために、足場を組まないといけない。
足場を組むとなると、我が家の敷地だけでは作業できず、隣家の水田に入る許可が必要。
…と、どんどん大ごとになって、足場は数日間お借りすることになるのでレンタル費用もかさんでいる。
先週末に足場を組んで、その後で雨樋屋さんもきて、作業手順の確認。
ここで、パーゴラの「家との接続部分」の改良の際に、本来竪樋が通る部分をふさいでしまっていたことが発覚。
パーゴラを組んだ大工さんに連絡が行き、竪樋の通り道をふさいでしまっていた部分を無くす。
（幸い、木材をねじ止めしただけだったので簡単に外せた）
外したら、組み立て後に塗装していたペンキが「塗り残し」状態になってしまったため、ペンキ屋さんに連絡が行ってほんの少しの部分を塗りなおす。
そして、いよいよ雨樋屋さんが作業したのが、先週の前半。
週の後半雨となってしまったので足場の解体作業に影響が出た。週末になって、やっと工事完了。
10月前半に被害が出たので、修復まで4か月弱。
しかし、あの台風での被害は大きく、まだ修復できていない家も多いそうだ。
4か月での修復は、早くはないが、決して遅いわけではないらしい。
まぁ、我が家的には特に問題ない。
「工事開始が年明けにはなる」と言われていて、実際の工事開始は年明け早々。
1か月以内に完了までできたのだから、予定通りだ。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
中国で新型コロナウイルスによる肺炎が広がっており、すでに死者が170人を超えたとか。
アメリカでインフルエンザが猛威を振るっており、死者は少なく見積もっても8000人を超えたとか。
物騒な話が世の中を騒がしているが、ごく普通の風邪をひいた。
今週の頭あたりから、ちょっとのどが痛いなーとか、だるいなー、くらいには感じてきたのだけど、昨日になって微熱が出始め、今日はずいぶんと体がだるい。
昨日は朝の段階では微熱以外の兆候はなかったので仕事をしていたのだが、午後になってだるくなってきたので、少し離席して寝させてもらった。
今日は、朝からだるいので仕事を休みにしてもらった。
（ここらへん、在宅でフリープログラマをやっているので、ある程度融通を利かせてもらえる）
しばらく寝ていたのだけど、先ほど目が覚め、調子が良いので日記を書いている次第。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |