■ 3月1日

PostgreSQL で。

testdb=# SELECT * FROM fruit_price; name | shop1 | shop2 | shop3 | shop4 | shop5 --------+-------+-------+-------+-------+------- banana | 100 | 200 | 300 | | apple | 200 | 250 | 500 | | orange | 80 | 100 | 90 | 120 | 250 melon | 500 | 800 | | | (4 rows)

この表を、横に連なっているところを縦に、

banana 100 banana 200 banana 300 apple 200 apple 250 apple 500 orange 80 ...

と出力したい。 本来やりたいテーブルでは、LEFT JOIN で色々繋げたり、WHERE で絞っているので、UNION で繋げると長くなってしまって、何とかならないかと考えていた。 調べてみると、CROSS JOIN を使って取り出すことができるようなので、やってみることに。

testdb=# SELECT fprice.* FROM ( SELECT name, CASE serialnum.n WHEN 1 THEN shop1 WHEN 2 THEN shop2 WHEN 3 THEN shop3 WHEN 4 THEN shop4 WHEN 5 THEN shop5 END AS shop FROM fruit_price CROSS JOIN (SELECT n FROM generate_series(1, 5, 1) AS n) AS serialnum ) AS fprice ; name | shop --------+------ banana | 100 apple | 200 orange | 80 melon | 500 banana | 200 apple | 250 orange | 100 melon | 800 banana | 300 apple | 500 orange | 90 melon | banana | apple | orange | 120 melon | banana | apple | orange | 250 melon | (20 rows)

うまく取り出せている。 null の削除と、name で並び替えて。

SELECT fprice.* FROM ( SELECT name, CASE serialnum.n WHEN 1 THEN shop1 WHEN 2 THEN shop2 WHEN 3 THEN shop3 WHEN 4 THEN shop4 WHEN 5 THEN shop5 END AS shop FROM fruit_price CROSS JOIN (SELECT n FROM generate_series(1, 5, 1) AS n) AS serialnum ) AS fprice WHERE fprice.shop IS NOT null ORDER BY name ;

こんな形になった。 もう少しなんとかなりそうな気もするけど、時間もないのでこの辺りで妥協する。

■ 3月2日

昨日の続き。 実際に使うときには name ごとに集約関数を使っていた。

SELECT name, sum(shop) AS sumshop FROM ( SELECT name, CASE serialnum.n WHEN 1 THEN shop1 WHEN 2 THEN shop2 WHEN 3 THEN shop3 WHEN 4 THEN shop4 WHEN 5 THEN shop5 END AS shop FROM fruit_price CROSS JOIN (SELECT n FROM generate_series(1, 5, 1) AS n) AS serialnum ) AS fprice WHERE fprice.shop IS NOT null GROUP BY name ORDER BY name ;

この sumshop が800以上のときに表示させたかったので、WHERE に追記すると。

testdb=# SELECT name, SUM(shop) AS sumshop FROM ( SELECT name, CASE serialnum.n WHEN 1 THEN shop1 WHEN 2 THEN shop2 WHEN 3 THEN shop3 WHEN 4 THEN shop4 WHEN 5 THEN shop5 END AS shop FROM fruit_price CROSS JOIN (SELECT n FROM generate_series(1, 5, 1) AS n) AS serialnum ) AS fprice WHERE fprice.shop IS NOT null AND sumshop >= 800 GROUP BY name ORDER BY name ; ERROR: 列"sumshop"は存在しません LINE 16: WHERE fprice.shop IS NOT null AND sumshop > 800 ^ HINT: Perhaps you meant to reference the column "fprice.shop".

エラーが出てしまった。 確かに、順番を考えると駄目そうな気もする。 少し考えて、HAVING を思い出した。 やってみる。

testdb=# SELECT name, SUM(shop) AS sumshop FROM ( SELECT name, CASE serialnum.n WHEN 1 THEN shop1 WHEN 2 THEN shop2 WHEN 3 THEN shop3 WHEN 4 THEN shop4 WHEN 5 THEN shop5 END AS shop FROM fruit_price CROSS JOIN (SELECT n FROM generate_series(1, 5, 1) AS n) AS serialnum ) AS fprice WHERE fprice.shop IS NOT null GROUP BY name HAVING sumshop >= 800 ORDER BY name ; ERROR: 列"sumshop"は存在しません LINE 18: HAVING sumshop >= 800 ^ HINT: Perhaps you meant to reference the column "fprice.shop".

あれ？と思って、HAVING を SUM にしてみた。

testdb=# SELECT name, SUM(shop) AS sumshop FROM ( SELECT name, CASE serialnum.n WHEN 1 THEN shop1 WHEN 2 THEN shop2 WHEN 3 THEN shop3 WHEN 4 THEN shop4 WHEN 5 THEN shop5 END AS shop FROM fruit_price CROSS JOIN (SELECT n FROM generate_series(1, 5, 1) AS n) AS serialnum ) AS fprice WHERE fprice.shop IS NOT null GROUP BY name HAVING SUM(shop) >= 800 ORDER BY name ; name | sumshop -------+--------- apple | 950 melon | 1300 (2 rows)

そういうことみたい。 実際のプログラムで初めて HAVING を使ったかも。

■ 3月3日

Javascript を書いていて。
onclick="clickCall();"
のように「;」を入れてしまいがちで、無くても良いのは知っているのだけど。 果たしてどっちが良いのかちょっと調べてみた。 すると、今では Automatic Semilocon Insertion という機能があって、そもそもセミコロンをほとんど入れないで書けるのだとか。 そんなコードを見ていたら、なんと言うか気持ち悪い。 C 言語から入った人間としては、逆に読み辛くなっているが、最初からこれで入った人は違和感がないのかもしれないけど。 onclick のセミコロンごときで悩んでいたのが馬鹿な感じがしてきた。

■ 3月4日

Wireshark を起動したら、3.0.0 にアップデートできると画面が出た。 新しい方が機能が増えて快適かもしれないが、ここはメジャーアップデートなので少し様子を見た方が良いかもしれないと、アップデートはちょっと保留して。 リリースノートを見ると、bug fix と新しいプロトコルの対応が多いようだけど、気になったのがインストーラー同梱の WinPcap が Npcap に変更になったこと。 なにやら Npcap の方がメンテナンスされているらしく。 Npcap が気になるので、暫くして大きなバグが無さそうだったら、3.0.0 を試してみようかな。

■ 3月5日

html を書いていて。 できるだけ Javascript だけで収めるようにしているが、手間を考えて仕方なく JQuery も使うことがある。 それを Javascript だけで書いたとして、どのぐらい実行速度に影響するのか。 ほとんど変わらないのだったら、気にせず JQuery のパーツなんかを使うのだけど。 それを絶対的に比較するのは難しいところもあるが、どこかで Javascript だけの場合と JQuery を使った場合と、どのぐらい差が出るのかという web サイトがあるか調べてみたものの、見つからず。 JQuery に対する姿勢をどうすれば良いのかと、ここのところちょっとモヤモヤしていて。 答えが出ないので、少なくとも読み込み時間分は早くなるので、これまで通りになるべく JQuery を避けるというスタンスで行こうかなと。

■ 3月6日

庭に蒔いたエンドウが大きくなってきたので、支柱が必要になってきた。 家に支柱が何本か余っていると言えば余っているが、100円ショップで買った支柱だと土に打ち込んだとき、土中の石にぶつかるとすぐに折れてしまう。 なので、手元にある鉄筋が使えないかと考えた。 鉄筋だと外で使うとすぐに錆びてしまうのと、茎に触れると傷つくので、その対策が必要になる。 塗料でコーティングするのも面倒だし、何か良い方法がないかと思案していたら、熱収縮チューブがあると閃いた。 さっそく、Monotaro で探してみるが、長いものはかなり高い。 困ったときの Amazon で、大陸から直接送られてくる謎のものがかなり安く売っている。 15mm サイズの 10m で1000円ぐらいなので、1本買ってみることに。 いつ届くかわからないし、屋外使用で割れたりしないか、不明なところが大きいけど。

■ 3月7日

Windows を使っていて、たまにドライブを間違えて DVD ドライブをクリックしてしまうことがある。 その度にドライブのトレーが開いて、少し待たされたり、トレーを閉じたりする必要があったり。 少し考えてみたのだけど、ここ1年どころか2年ぐらい光学ドライブを使っていない気がして。 仕事場では新規プリンターを導入したときに、セットアップソフトが必要になって1回使ったが、それを入れても1回だけ。 もう外してしまおうかと思ってきた。 家では USB さえあれば困らないし、今度 PC を開けたときに外してしまおう。

■ 3月8日

物干しの竿が折れたり古くなってきているので、ステンレスパイプに置き換えようと、だいぶ前から考えていた。 せっかくなので、マストの幅も広げて 4000mm 近くにしたい。 そこで気になるのが、洗濯物を干したときにどれだけたわむのかどうかという点。 それを出すには比重とかヤング率とか、色々計算しないといけないので、簡単に出せる方法はないものかと検索してみた。 計算してくれる web ページが見つかったので、さっそく使ってみた。
らくちん計算.com - 梁のたわみ計算
25mm 径の 1mm 厚のステンレスパイプを考えていたけど、4000mm となると自重たわみだけで 18mm にもなる。 ここに 20kg (196 N) のものを干したら、たわみ量は 253mm にもなる。 中心のみにそれだけ重いものを下げることはないだろうけど、でもこれじゃ折れる可能性が高い。 ステンレスパイプの規格を見ながら、色々と値を変えてやってみるが、パイプ径は 38mm 欲しいところだな。 38mm のパイプはどれだけのものか、ノギスがないので今度ホームセンターに行って感触を確かめてみることに。 先に計算しておいてよかった。

■ 3月9日

PostgreSQL でクエリを書いていて。

WHERE senddate >= '2019-02-01' AND senddate < '2019-03-01'

と書いていた。前に作られていたプログラムのクエリを確認すると。

WHERE date_part('year', senddate)='2019' AND date_part('month', senddate)='2'

となっていた。 こんな書き方もあるのかと勉強になって。
このプログラムは1年分のデータを月単位で取得しているので、上記の絞り込みを1つのクエリで12回やっている。 果たして、スピードの違いはどのぐらいあるのか、ちょっと試してみた。 手元のデータで、date_part を使用すると。

Planning time: 20.120 ms Execution time: 522.661 ms

日付の範囲を指定すると。

Planning time: 20.243 ms Execution time: 486.838 ms

だった。何度かやってみたが、やっぱり同じぐらいの時間。 範囲指定の方がちょっと早いみたい。 プログラムからクエリを吐くときは date_part の方が楽だけど、今回は範囲指定にした。

■ 3月10日

色々と人様のブログを眺めていたら、パナソニックの生ごみ処理機を使ってると書いてあった。 Panasonic がそんなもの出しているのかと調べてみた。
家庭用生ごみ処理機 MS-N53
良さそうな感じなのだけど、6万円もする。 これだけ高いと、簡単には手が出ないな。 さらに電気代もかなりかかるようだし。 欲しいと言えば欲しいけど、この値段だったら無理なので、あきらめる。

■ 3月11日

先日 Monotaro で注文したら、まさかの4個口の荷物になったようで。 それだけならまだ良いのだけど、あろうことか配送会社が3つとなった。 さらに Amazon で別な買い物もしていたので、ヤマト運輸も加わって今日は配送会社が4社来ると言う状態。
心配だった西濃運輸がちゃんと来たので、不思議に思っていたら近所の人に場所を聞いたのだとか。 今日来たヤマト運輸、佐川急便、日本郵政、西濃運輸と来た中で、やっぱりヤマトと佐川は安心できるし、配達する人も笑顔だし。 そんな感じで、今日は料理の手を何度か止めて対応する必要があった日だった。

■ 3月12日

スマートフォンのスペックを見ていたら、位置情報を取得するための機能で。
GPS, A-GPS, Glonass, Beidou
と書いてあった。Glonass までは良いとして、Beidou って何？と思って。 検索エンジンの Baidu と関係あるのかと思いながら調べてみると、北斗衛星導航系統という US の GPS に対抗して作られた中国の測位システムで、既に Glonass より衛星数は多いらしく。 GPS と組み合わせれば精度が格段にあがりそうだけど、中国のやっていることだから昔の GPS と同じように何かあると精度を落としたり、使えなくなりそうな気がして怖い部分もある。 個人的には準天頂(QZSS)を使いたいのだけど、海外製のスマートフォンだと対応していないことがほとんどなので、難しそう。

■ 3月13日

仕事場の窓際のスペースで、夏野菜の苗を少し育てている。 気になっているのが日当たりで、東向きの窓なので午後は日が当たらないし、窓から 300mm ぐらい離れて置いているので、日当たりにどのぐらい影響があるのか疑問だった。 せっかく Android の端末があるので、照度計で計測してみた。
窓の内側でも日が当たっていると、10000 lux 以上出たりするが、日陰になると 3000 lux が限度。 さらに窓から 300mm も離れるた日陰では、晴れているにも関わらず 600 lux ぐらいに落ちてしまう。 やっぱり、窓になるべく近づけるべきみたい。 窓際は植物だらけなので、なんとか寄せてみるかな。

■ 3月14日

昨日は月例の Windows Update があって。 仕事場の Windows 10 の PC で、何故だか1台アップデートされていない様子。 手動でアップデートさせようと思ったが、コントロールパネルを開いても Windows Update させる場所が見つからない。 2分ぐらい探して、ふと、スタートメニューにある「設定」を思い出した。 さっそく「設定」を開くと、「更新とセキュリティ」が見つかって、手動アップデートさせることができた。 前も書いたかもしれないけど、「コントロールパネル」と「設定」と2つあるのはわかり辛いので、1つにまとめるか、どちらからでも同じ画面が出るようにして欲しい。

■ 3月15日

PostgreSQL で、UNION ALL を使っていた。 この UNION ALL で接続する数を気にしていなかったが、2つと3つでは動作が違うことに戸惑った。

testdb=# SELECT * FROM fruit_price; record | name | price0 | price1 | price2 ------------+--------+--------+--------+-------- 2019-02-13 | banana | 100 | 200 | 300 2019-03-09 | apple | 200 | 250 | 500 2019-03-12 | orange | 80 | 100 | 90 2019-03-20 | melon | 500 | 800 | 900 (4 rows)

こんな感じのテーブルがあって。 本当の環境はテーブルは3つだったのだけど。

testdb=# SELECT null AS record, name, price0 AS price FROM fruit_price testdb=# UNION ALL testdb=# SELECT record, name, price2 AS price FROM fruit_price; record | name | price ------------+--------+------- | banana | 100 | apple | 200 | orange | 80 | melon | 500 2019-02-13 | banana | 200 2019-03-09 | apple | 250 2019-03-12 | orange | 100 2019-03-20 | melon | 800 (8 rows)

と2つでは問題ない。 3つにしてみると。

testdb=# SELECT null AS record, name, price0 AS price FROM fruit_price testdb=# UNION ALL testdb=# SELECT null AS record, name, price1 AS price FROM fruit_price testdb=# UNION ALL testdb=# SELECT record, name, price2 AS price FROM fruit_price; ERROR: UNIONの型textとdateを一致させることができません LINE 5: SELECT record, name, price2 AS price FROM fruit_price;

となってしまうのである。 先に null を2つではなく、実体のあるものを出すと問題が起きないので、UNION ALL の順番を変えれば良いが、ORDER BY でまた並び直さないといけない。 それだったらと。

testdb=# SELECT null::date AS record, name, price0 AS price FROM fruit_price testdb=# UNION ALL testdb=# SELECT null::date AS record, name, price1 AS price FROM fruit_price testdb=# UNION ALL testdb=# SELECT record, name, price2 AS price FROM fruit_price; record | name | price ------------+--------+------- | banana | 100 | apple | 200 | orange | 80 | melon | 500 | banana | 200 | apple | 250 | orange | 100 | melon | 800 2019-02-13 | banana | 300 2019-03-09 | apple | 500 2019-03-12 | orange | 90 2019-03-20 | melon | 900 (12 rows)

として結果は得られた。 最初だけ null::date を付ければ良いみたいだけど、null にも型を付けるのが不思議な気分で。 今日のところは深く考えないことにする。

■ 3月16日

某所のブログによくわからないアクセスが続いている。 同じページに対してのアクセスで、リファラは無く、Mac OS X の Firefox 62 からで、画面解像度も全て 1200 x 800 のクライアント。 1時間に数回アクセスしてきて、その度に IP アドレスは違うのだけど、140.227.0.0/16 の範囲となっている。 ロシアとか中国からだったら、何かをやらかして来ているかもしれないと思うが、どうも国内からのアクセスのようだし。 広告もちゃんと表示しているようなので、IP アドレスの範囲でブロックしようか悩ましいところ。 もう少し様子をみてみることに。

■ 3月17日

桜の枝を落としたいのだけど、どうにも道具なしの木登りでは登っていけない場所の枝で。 下から切るにしても 4m 以上も上なので、ちょっとした梯子に登ったところで届かない。 結び目を作ったロープを投げて、枝に登ろうかとか、縄梯子の方が良いかなと Amazon を調べていた。 今日、ホームセンターに行くと、4m に伸びる鋸が売っていた。 岸本農工具製作所の 1470A というもので、8000円ぐらい。 重さは 1.4kg だったが、果たして 4m も伸ばして直径 100mm ぐらいの枝を落とせるのか。 疲れそうなのは確実だけど。
縄梯子だと5000円以下で売っているが、どうやって掛けるかが問題になるし。 そうこう考えているうちに花が咲いてきて、毛虫の時期になりそうである。 また来年かな。

■ 3月18日

昨日の少し続きで。 Amazon で梯子を検索すると、収縮式の梯子が色々と出てきた。 最近はこんな梯子が流行っているのかと思わず見てしまった。

収縮式だと、重さは仕方ないにしても、使わないときはかなりコンパクトになる。 良くできているというか、これまで無かったのが不思議なぐらい。 屋根の修理とかしないといけないので、今度買ってみるつもり。

■ 3月19日

web ページが更新されたかのチェックをいくつかの方法でしている。 その中の1つで、Opera から Add-on の Distill Web Monitor を使っている。 今日、家の Opera で更新のチェックがされなかったようなので、管理画面を開こうとしたら。

何故かログイン画面しか開かない。 何かの起動のタイミングでそうなったのか、これから登録しないと使えないのか。 なんだか嫌な感じである。 仕事場でも少し使っているので、明日試してみて考えることに。

■ 3月20日

昨日の続き。 仕事場の Opera で Distill Web Monitor を開いてみたら、問題なく動いている様子。 仕事場では 1 つの web ページの監視しかしていないけど。 何故、家の Opera だとログイン画面になったのだろう。 気になったので家の PC を再起動してみたりしてみたけど、現象変わらず。 いっぱい登録してあったし、そのためだけに Opera を動かしていたような感じなので、これからどうするか考え中。 数が多くなったことが原因なのかな。

■ 3月21日

Explorer を開いたときに出てくる「最近使用したファイル」を残さないようにできないかと言われて。 そんなぐらいだったら、自分で調べてやってと言いたいところを我慢して「なぜ残さないようにしたいのか」とあえて聞いてみた。 「見られたくないから」という意味のない答え。 それ以上聞いても時間の無駄っぽいので Exploere の設定でさっと変更しておいた。

Windows10 なのでタイムラインでもわかるのになと思いながらも、仕事が増えるので本人には伝えないでおいた。

■ 3月22日

VLC で TS ファイルな動画を再生したのだけど、えらく音が小さくて。 Windows 10 の「映画&テレビ」だと音は小さくならない。 これは何でだろうかと色々見てみると、動画の音声が 5.1ch になっていた。 多分原因はそれなんだろうけど、VLC の設定を色々と変更してみたが、音は小さいまま。 VLC のバージョンが 2.2.4 と古いせいなのかと思って、3.0.6 にしてみたけど現象変わらず。 これは高いスピーカーを買えというお告げなんだろうか。 さすがに仕事場にスピーカー6つも置けない。

■ 3月23日

手動でメールの送信テストをしたくて。 日本語も入れたかったので、手元の Poderosa で SMTP サーバに JIS で接続しようと思っていたが、ターミナルの文字コードとして JIS がない。 仕方なく、PC に予備的に入っていた RLogin を実行してみたが、やっぱりまさかの JIS がない。 これはエンコードを UTF-8 にして、メール本文もエンコードしろということなんだろうか。 ちょっと面倒なので、TeraTerm をインストールして JIS で送った。
ターミナルエミュレータとして JIS なんか使うのは SMTP とお話をするときぐらいだろうけど、あると助かるので RLogin でも追加して欲しいところ。 それとも、そんな時代じゃないと考えるべきなんだろうか。

■ 3月24日

これから暖かくなると、部屋の観葉植物にも畑にも虫が出てくる。 これを農薬を使わずになんとか減らせないかと。 土の中の虫だと、木酢液なんかを使うけど、葉物に付く虫だと難しく。 web で少し調べてみると、ニームオイルなる自然由来の虫よけを見つけた。 なんでも、ニームの木から採取されたもので、忌避効果があると。 値段はちょっと高めなのだけど、買ってみようか、どうしようか。 少し考えて、試しに1本買ってみることに。 いっぱい買った方がお得なのだけど、この値段で効果がなかったら、目も当てられないし。

■ 3月25日

音楽 CD を仕事場でも聞こうかと思って、出してきた。 仕事場の PC で CD を入れて聞くのも面倒なので、ファイル形式は何でも良いから変換して USB メモリに入れたい。 試しに VLC を起動して、CD から変換をかけてみるものの、0 バイトのファイルが出来るだけで変換してくれない様子。 VLC の変換機能は前々からうまく動いたことがないので、期待はしてなかったけど。 じゃ、どうしようかと検索してみると、Windows Media Player でできるらしく。 それも MP3 になるようなので、やってみたらあっさり MP3 ファイルができあがった。 普段 Windows Media Player なんて使わないので、こんな機能があるのを知らなく、進化しているんだなとちょっと関心して。

■ 3月26日

某所で消防設備点検があった。 火災報知器のテストをしていたので、原理を聞くと「このタイプは一定時間に30度以上温度があがったら反応します」とのこと。 だから、氷点下の日にエアコンを付けて急激に温度が30度以上あがると、検知してしまうのだとか。 一定時間がどのぐらいなのか聞くと、「製品によって違うのと、熱の伝導速度が影響するので厳密ではないが、概ね1分ぐらい」と。 そんな単純な仕組みだとは。 氷点下の日にテストしてみようかな。

■ 3月27日

先日、電話で「スリムワレのアップデートが毎回出てどうとかこうとか」そんな問い合わせがきて。 何を言っているのか良くわからなかったけど、ちゃんとしたソフトウェアじゃなさそうな感じで。 今日、その PC を見てみたら、slimware と書いてあって、これのことかと判明。

「プログラムのアンインストールまたは変更」からあっさりアンインストールできたのだけど、ちょっと心配なので、レジストリのチェックもしてまた起動しようとしてないかなどのチェックもして。 10分ぐらいで削除作業完了。 横で見ていた人に「見てたけど、何やったかさっぱりわかりませんでした」と言われて、「呪いを解除する魔法をかけておきました」と返しておいた。 問題はどこからこの slimware というソフトが入ったか、なんだけど。 本人はさっぱり記憶がないらしく。 しばらく様子見ということになった。

■ 3月28日

日本郵政から不在票が入っていた。 差出人が AC アダプターと書いてあって、それは違うだろと思いながら再配達をお願いした。 送りつけ詐欺もあるので、そこはしっかり書いて欲しかったところ。
荷物が届いたので、荷物を見ると差出人はソフトバンクになっていた。 やっぱり、配達の人の怠惰というか。 この荷物はなんだろうなと少し考えて、そう言えば前に ADSL モデムの AC アダプターに不具合があるとかで、交換になるとお知らせが届いていたのを思い出した。 届いた AC アダプターはそれのようである。 今度、時間があるときに交換しておこう。

■ 3月29日

某所に Lenovo の H520s という PC が余っていて、Core i3 を搭載しているし、メモリも 4GB あるので何かやらせようかと考えた。 マイニングかなと考えて調べてみたが、電源が 240W なのでグラフィックカードを刺すには不足する。 さらに PC はロープロファイルじゃないと刺さらないし、マイニングは無理そう。 さらに考えてみたけど、Linux 入れて web サーバの予備にすることぐらいしか思いつかなかった。 何か良い利用法は無いものかな。

■ 3月30日

今年のゴールデンウィークは10連休らしく。 年号変更でシステムの稼働チェックを行うので、そんな連休は取れないが、それでも半分以上は取れる予定。 じゃ、ウッドデッキ拡張計画を進めようかと考えて。 木材はゴールデンウィークに近づくと品数が少なくなるため、早目に手に入れておこうかと思い立った。 通販で木材の値段を見るとかなり安く売っているが、材を選べないのと、送料が割高になるのと、配送に時間指定ができなかったりと。 使い物にならないぐらいの木材が来ることもあるみたいだし、ちょっと手が出せない。 かといって今の車だと 2500mm 以上の木材が運べないので、ホームセンターで購入する場合は、カットサービスを使うか、レンタルトラックサービスを使う必要がある。 色々と悩ましいところ。 天気次第だけど、ゴールデンウィークは基礎周りだけでいっぱいいっぱいの気もするし、ちょっと計画を考え中。

■ 3月31日

とある会社で商品の申し込み応募要領が出ていた。 いまどき珍しく、葉書での応募と書いてあり、そこまでは良かったのだけど。 説明に「官製はがきに～」と書かれていて。 民営化して10年以上経つのに、「官製」と呼んでいるのは、意味を理解していないからじゃないかと。 試しに「官製はがき」で検索すると、ごろごろと web ページが見つかるし。 「官製はがきが入手できません」と問い合わせてみようかと考えてしまった。