0時に寝て4時に起きて7時に起きた。晩ご飯に餃子の中身とニラと卵を炒めたものを食べてわりとよく眠れた。

遊撃の開発

ちょっと前に自分が 遊撃としての役割 を担っているのではないかと書いた。ある機能開発で javascript を用いてカスタムスクリプト を実行できるようにしたい。スポット的に私の手が空いていて手伝ってと言われたので実装している。開発していると集中しているから時間が経つのが早い。あとコードレビューのときよりもしっかりコードを読み込んだり、振る舞いをシミュレーションしたりするから、コードレビューのときに気付かなかったことや見逃したことにもい気付く。そして、それもついでにリファクタリングしていく。チームのメンバーに、過去に書いたコードをどんどん書き直すのはよいことだというのを、遊撃しながら教えていければいいなとも思う。課題管理システムの issue に調べたことや設計の素案のようなコメントをしていると、メンバーもコメントしてくれたりして、考え方や検証したことをどんどんテキストにして書いていく、言語化していくことの良さも、遊撃の中から学んでくれたりすると嬉しい。開発しながら、メンバーの教育や指導をどう進めるのがいいかな？とかも考えながら働いているのがマネージャーにやっているなという自己満足にもなっていたりする。だいぶマネージャーとしても自分自身にも慣れてきたんじゃないかと思う。

23時に寝て2時頃に少し吐いて起きた。夜遅めに日本酒飲んでいい気分で寝たものの、もう夜に食べたらダメな体になりつつある。4時ぐらいまで起きててそれから寝て7時に起きた。

echo の静的ファイルの扱い

web api のドキュメントは openapi スキーマを使って生成 している。本当はこのドキュメントを gitlab pages で公開させたいのだけど、まだそのインフラ構築ができていなくて先送りになっている。いつもローカルで gitlab ci/cd がビルドしたドキュメントをみていたのだけど、ある機能開発をするときにローカルで web api ドキュメントみるの飽きたなと思って、web api サーバーに同梱してしまえと思い立った。テスト環境の web api サーバーは常に動いているのだから、そこに web api のドキュメントが同梱されていて、なんの不都合があろうか？ (いや、なにもない) 。

次のドキュメントに echo で静的ファイルを扱う方法が書いてある。

• Static Files

ミドルウェアで実装されているようで簡単に静的ファイルを返せる。指定したパスのディレクトリ配下を扱えるのが Static で、指定したパスのファイルを扱うのが File になる。web api ドキュメントのようなものならキャッシュしてもいいなとは思ったものの、次の issue によると v4 ではミドルウェアで自前実装しないといけないらしい。v5 ではその仕組みが echo の機能として入るかもしれない。

• TTL (Cache-Control header in response) for static files #1902

その後、gitlab ci/cd で web api サーバーのビルド後、openapi.yml からドキュメント生成をして、任意の static ディレクトリに配置するように設定した。docker のマルチステージビルドを使うと簡単にできる。バックエンドやっていて、サーバーとインフラの両方に手を入れて機能を作っていくときの、うまくできると利便性と達成感の両方を得られるのが楽しい。web api サーバーがドキュメントを提供することは、要件に含まれるわけでも、誰かに指示されたわけでもない。私が勝手にローカルでドキュメントみるの飽きたと思って、勝手に作って、勝手に動くようにしただけ。こういう開発の遊びのゆとりや権限をチームのメンバーにも与えられるようにしていきたい。開発が楽しくて悪いことはなにもないと思うんよね。

昨日から実家に帰ってた。23時に寝て5時に起きた。親が3時ぐらいから起きているから4時ぐらいから布団の中で起きてた気がする。親がだんご転がしで登る山の場所を確認しておきたいというから7時から山登りしてきた。

35日 (だんご転がし)

住職が来る前にだんご転がしを済ませておく。親戚に9時半に近所のお寺に集まってもらってだんご (おにぎり) を持って山登りをする。私は今日2回目。

言うても低い山なので往復20分ぐらいの山登り。登ったところから1人3個、崖に向かって後ろ向きにおにぎりを谷へ放り投げる。三十五日目の山参り というタイトルで日本昔ばなしでも放送されていたらしい。ググれば youtube でみつかるけど、著作権的によいのかどうかわからなかったのでここでは紹介しない。

11時から住職に来てもらってお経をあげていただく。お経後の住職の法話でだんご転がしの風習について話しがあった。そこで日本昔ばなしでも取り上げられたというのを教えてもらった。日本では淡路島にしか残っていない風習だという。その理由を聞いてみたら住職は次の3つをあげていた。

• 島であること
• 島民の大半が 真言宗 であること
• お米が取れる地域であること

仏教の宗派が異なれば葬式の風習も異なる。たまたま島なので外部の影響を受けなかったのではないかという。昔は兵庫の北部や徳島県でもだんご転がしの風習はあったものの、徐々に廃れていったのは他の宗派の影響があるのではないかと話されていた。だんご転がしと言いながら実際はおにぎりを転がすのもややこしい歴史的経緯になっている。昔はお米は貴重であったため、おにぎりの代わりに団子を放っていた時代があって、その後またおにぎりに戻ってきたのではないかと考えられる。現代ならおにぎり転がしというのが正しい。お餅を祀るという習慣も関西では普通だが、関東では行われないという。それもお米が取れる地域の影響があるのではないかと話されていた。歴史の勉強になっておもしろかった。

本髙砂屋の金つば

本髙砂屋 という老舗の和菓子屋さんがある。洋菓子も売っているようだけど。35日に来てくれた親戚に配るためにお土産に買って帰っていた。これまでもお店があるのは知っていたけど、購入する機会がなくて初めてお店に入って買ってみた。詰め合わせは自由に好きなものを組み合わせてくれるという。

現在の「角きんつば」は、神戸元町の紅花堂（現在の本高砂屋）の創業者である杉田太吉により明治時代に考案されたものである。

wikipedia: きんつば

wikipedia によると、当初は刀の「つば」のような丸い形状で、その色から銀つばと呼ばれていたという。大阪で発明されたものが江戸に伝わったときに銀よりも金の方が景気がよいという理由で名前が金つばになったらしい。またいまの四角い金つばは本高砂屋さんがオリジナルで始めたことらしい。なるほど。歴史つきの神戸のお土産として素晴らしい。甘さ控え目で上品な風味になっている。あんこの甘いのが好きな人とそうじゃない人で好みは分かれるかも？私は甘さ控え目の方が好みかな。普通においしいと思う。

22時に寝て2時前に吐き気で起きて少しだらだらして寝て7時に起きた。

ストレッチ

今日の開脚幅は開始前154cmで、ストレッチ後158cmだった。あまり数値は振るわなかったものの、この1ヶ月ぐらいではもっとも復調しつつある。まだ腰の張りがやや残っていて全快とまではいかないものの先週よりはよくなりつつある気はする。先週から左右への開脚以外に前後の開脚のときの股関節のストレッチを重視するよう、トレーナーさんからも指示はあったものの、今週は全然そんな余裕がなくてあまり取り組めなかった。それを余暇でうまくできなかった分の、数値の悪化かなとも受け取れた。

2-2. 傾聴・可視化・リフレーミング

エンジニアリング組織論への招待 のメンタリングの技術の章を読み直し。前回 からだいぶ間があいた。

メンターはメンティに対して「問題を解決してあげよう」ではなく「モヤモヤしていない問題に変換してあげよう」と考えることが重要。問題を次のように考え、

• 感情的に固執していて解けないので「傾聴」をする
• 客観視できずに解けないので「可視化」をする
• そもそも解けない問題なので前提を変える「リフレーミング」をする

というのが、メンタリングで意識すべき流れになる。

共感と同感の違い

• 共感という言葉の意味は「相手がそのような気持ちになった理由を理解する」こと
• 同感は「自分が相手と同じ気持ちになる」こと

傾聴において示すべきことは、「共感」であって、「同感」ではありません。

認知フレームとリフレーミング

• 人はありのままに物事を見られない
  • 人は認知する枠組みの範囲でしか処理できない
  • この枠組みのことを「認知のフレーム」と呼ぶ
    • この外側にあることは「心理的な盲点」と呼ばれる
• 対話によって認知フレームを変えることを「リフレーミング」と呼ぶ
  • 「解けない問題」を「解ける問題」へと変えていく

確認された前提を「一旦、この前提がなかったらどうなりますか？」というように外して考えるようにすることで、リフレーミングを促すことができます。 また、この中で「一番重要だと思うものは何ですか？」というように前提の優先順位を問うこともリフレーミングを促します。気になって仕方なかったことが、実はあまり重要ではないかもしれないと気がつく契機になります。

「情報の非対称性」を解消するには、

• 自分の情報を相手に伝える
• 相手の情報を自分が聞く

という行動をとればよいのですが、この当たり前のことができなくなってしまうケースがある

これは、メンター役になる人に対しても重要な警句です。メンターは、メンティの問題を「自分の課題」として捉えてはいけません。メンターにとっての課題は「メンティを自立的な問題解決」に導くことであって、「メンティの課題を解決すること」ではないのです。

この節を読み終えて、課題管理とは、メンターを必要とせず、自分で自分をメンタリングするツールとも言い換えられるかもしれないと思えた。課題管理を習熟すると自分で自分の間違いに気付けるというメリットを周りに伝えたりしていたことがメンタリングで大事なことのいくつかの共通することが書いてあった。

車を運転して実家へ

明日は父の35日なので夕方から購入した車で初めて実家に帰った。神戸の高速道路の路面が少し濡れていたり北淡で小雪が降ってきたりして、さっそくタイヤ周りを汚れてしまった。まぁ仕方ないか。door-to-door で1時間15分ぐらいで実家に帰れる。高速バスで帰るとこんな段取りになる。

• マンションからバス停へ移動する (10分)
• バス停でバスが到着するのを待つ (待ち時間10分)
• 高速バスで移動する (1時間20分)
• バス停まで親に車で迎えに来てもらって実家へ移動する (15分)

待ち時間の調整が入ると2時間ほどはかかっていた。これが自分の都合で移動できるので調整時間がない分のストレスが溜まらない。帰ろうと思って1時間強で移動できる気楽さがある。

22時に寝て4時に起きて1時間ほどだらだらしていて8時に起きた。生活のリズムが少しズレてきてしまっている。

最後のコードリーディング

先週からコードリーディングの勉強会をやっていて今日が最後。今日の対象のプログラムは windows サーバーで動く c++ のコードなので私はどちらも素人であまりよく分からない。上長の判断で別チームのベテランの開発者に来てもらうとよいとアドバイスを受けてお願いして来てもらった。これは本当によかった。実装されたコードだけではなく、設計を見直した方がよい視点なども指摘してもらって、もう少し時間をかけてこの windows プログラムを改修した方がよいと私は判断した。windows サーバーをクラッシュさせてしまうリスクのあるサービスにフックして実行されるコードを書いているので、windows サーバーの振る舞いや異常系処理の経験がないと潜在的にリスクのあるコードを動かしてしまう。web のアプリケーションなら多少のバグは後で直せばよいけど、os をクラッシュさせてしまうものは慎重にレビューした方がよいように思えた。次回の定例で話題にあげて課題を掘り下げようと思う。結論としてはコードリーディングしてよかったという話し。

23時に寝て2時に起きてだらだらして寝て7時に起きた。テンカイチ 日本最強武芸者決定戦 という漫画を読んでた。

pure go の javascript 処理系

ユーザー定義スクリプトを実行する要件がある。システム管理者がスクリプトを書くなら javascript がいいかなと次のリファレンスを調べたりしていた。

• How to support custom Javascript scripting in Go Applications
• goja alternatives
• Choosing scripting extension - need advice

これらを読んだ結果として dop251/goja がよいだろうと判断した。README だけ読めばすぐに実装できてめっちゃ簡単で感心した。こういうライブラリを私も会社のプロダクトとして作ってみたい。万人が使うものではなくても、必要なときがたまにあって、すごく使いやすいみたいな。こんな感じで goja の機能を使ってライブラリ実装してみた。

type FunctionCaller func(funcName string, args ...interface{}) (interface{}, error)

func NewFunctionCaller(script string) (FunctionCaller, error) {
	vm := goja.New()
	_, err := vm.RunString(script)
	if err != nil {
		return nil, err
	}
	return func(funcName string, args ...interface{}) (interface{}, error) {
		f, ok := goja.AssertFunction(vm.Get(funcName))
		if !ok {
			return nil, fmt.Errorf("failed to get function: %s", funcName)
		}

		funcArgs := make([]goja.Value, 0, len(args))
		for _, arg := range args {
			funcArgs = append(funcArgs, vm.ToValue(arg))
		}
		value, err := f(goja.Undefined(), funcArgs...)
		if err != nil {
			return nil, fmt.Errorf("failed to call javascript function: %w", err)
		}
		return value.Export(), nil
	}, nil
}

Is it goroutine-safe? によると、goroutine-safe ではないので毎回 js の runtime を生成する必要がある。用途によっては、実行したいスクリプトが大きくなるとオーバーヘッドを無視できない状況もあるかもしれない。うちの要件は小さいユーザー定義スクリプトを実行するだけなのでおそらくそれほど問題にはならないだろうという想定。

2時に寝て7時に起きた。生活リズムがやや乱れ気味。メンバーの1on1以外はスポット的に時間が空いていてテックブログを書いてた。

フロントエンドの技術選定のテックブログ

顧問のはらさんに勉強会をお願いして、技術選定の観点を教えてもらい、その後 next.js と sveltekit でチュートリアルやって感触を確かめ、最終的には CTO 判断でエイヤで決めた。その過程や調査結果などをそのままテックブログに書いた。お手伝い先のテックブログも hugo で動いている。私にとっては慣れた環境なので環境構築やプレビュー確認などはすぐにできた。テーマの違いによるテーブルやスタイルの定義などを他の記事を参考にしながら調整するのに手間取ったぐらい。半日ぐらいがっつり時間をとって草稿を書き上げた。これからレビューしてもらって問題なければ公開することになる。私の名前で普通に書いたけど、それが OK なら事例紹介に近いものにもなる。いつも半年働いてから、私が自分で納得できる品質を提供できていれば事例紹介をお願いしている。いまじゃなくてももう3ヶ月経ってからでもいいかもしれない。

私は会社のテックブログを書くのが嫌じゃない。私ぐらいになると、あちこちの会社でテックブログを書いてきたからお手伝いした会社は記事を1つぐらい書いて記念を残したいとまで考えるようになってきた。昔、ある会社でお手伝いしたときに調査した技術情報を社内 wiki にまとめただけで、長文をちゃんと書ける人は少ないと高い評価を得たことがあった。テックブログを書く開発者が少ないことを考慮するとさもありなんと言えるかもしれない。

1時に寝て8時に起きた。寝坊して朝起きれないものの、わりかしよく眠れるようになってきた。

sveltekit の ui からのリクエスト

+page.svelte のスクリプトで onMount() を定義すると bff へ http リクエストを fetch できる。

<script lang="ts">
	import type { User } from '$lib/types/users';
	import { onMount } from 'svelte';

	let data: User[] = [];

	onMount(async () => {
		const r = await fetch('/api/users');
		if (r.ok) {
			data = await r.json();
		}
	});
</script>

bff 側では web api を提供する必要がある。それは +server.ts を定義することで実装できる。内部的にはバックエンドの web api を呼び出して、それを返すだけの実装になる。こういった連携も sveltekit だと簡単に実装できる。前のお仕事は bff も java で作っていたけど、bff なら node.js でいいんじゃないかと思うぐらいにはフロントエンドの技術に慣れてきた自分がいる。

起業相談

少し前にも起業相談 に乗ったが、まったく別の人で12月に起業された方が三ノ宮.dev のコミュニティに入られて起業相談にのってほしいというので行ってきた。個人でもわりと有名な方らしく、ある2つのキーワードでググるとトップに出てくる。スタートアップを目指している方で、できるだけ多くのお金を資金調達して作りたいものを開発したいという話し。いまは金融緩和から緊縮に向かう状況なのでベンチャー資金も渋い状況ではないかと推測する。そんな中で cto をどうやって探せばよいかという質問が大きな話題だった。資金調達する上でもちゃんとした cto がいる方が融資する側からみても印象が違うという。それはそうかなとも思う。

一方で cto を探すのは相当に難しいという話しを私からした。基本的には過去に一緒に働いた人でスキルのある人や同じ意思をもっている知人や友だちに依頼するのがよいだろうと。それも難しい話しだけど、cto 募集なんかでよい人がみつかる確率は低いし、ましては ceo が技術に明るくないのであれば応募してくる求職者のスキルや知識を評価するのも難しい。他のコミュニティメンバーも同意見で、最初は cto を雇わず、普通にテックリードになれる開発者を雇って、プロダクトを開発して実績を作って資金調達した後に再度 cto を探してはどうか？と提案した。

あと資金調達は実績がないと難しいから、最初はすぐにお金を稼げるプロダクト開発をして、それで十分な収益をあげ、その実績から資金調達するのはどうかといった計画の話しをしていて、それはもっと難しそうだと私からは感じた。お金のためだけにやりたくもないプロダクト開発を1-2年やって、その後に本当にやりたいプロダクト開発を資金調達してからやる。それぞれのプロダクトはまったく関係がなく、組織も2つになるという。そんなやり方で成功したスタートアップを私は聞いたことがない。組織の難しさをあまりにも軽視していて無謀だとアドバイスした。

私も起業して早3年が経った。マイクロ法人だから簡単でしょと言われたらそれまでなんだけど、起業相談を依頼されるケースも増えてきた。これはこれで顧問やコンサル業ができるのではないかと少し皮算用していたりする。

1時に寝て7時に起きた。冬のせいか、朝起きるのが辛くなってきた。自身の体調がパッとしないと思っていたらマシンにも移ってしまった。

デスクトップマシンの調子が悪い

何の前触れもなく os がいきなりストールする。これまでも稀にあったり、サスペンドから復帰しないとかも1ヶ月に1回ぐらいはあったりしていたけど、今日は2時間以内に3回発生した。使い始めてちょうど3年を超えたところなのでそろそろ故障が出てきてもおかしくはない。もっとも疑わしいディスクの S.M.A.R.T チェックをやってみた。SMART / Health Informationの内容 をみると、Percentage Used という値がメーカーが独自計算した耐久値を表しているとのころ。しかし、値は13%なのでまだまだ大丈夫そう。その他のエラーチェックなどでもまったく問題は検出されなかった。どうやらディスクではないみたい。

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        28 Celsius
Available Spare:                    100%
Available Spare Threshold:          50%
Percentage Used:                    13%
Data Units Read:                    48,536,210 [24.8 TB]
Data Units Written:                 57,978,947 [29.6 TB]
Host Read Commands:                 1,818,481,150
Host Write Commands:                1,973,810,058
Controller Busy Time:               9,182
Power Cycles:                       1,863
Power On Hours:                     4,576
Unsafe Shutdowns:                   80
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               28 Celsius
Thermal Temp. 1 Transition Count:   90
Thermal Temp. 2 Transition Count:   50
Thermal Temp. 1 Total Time:         2246
Thermal Temp. 2 Total Time:         50

nginx の multi upstream 対応

先週末の続き 。docker compose でデプロイして node.js 上のポートに http 接続できるところまでやっていた。nginx のリバースプロキシ経由でアクセスできるようにする。web api も外部から https 接続できるようにすると2つの upstream が必要になる。ホスト名を dns 登録していないから同じ ip アドレスでアクセスしているため、ポート番号を変えないといけない。そのまま server 設定を行うと location 設定が dry の原則に反してしまう。どうやったら再利用できるかを調べたら conf として外部に出してしまって include すればいいとあったので次のようにして再利用できた。これで node.js アプリは 443 を、web api は 8443 で https 接続できた。

http {

    upstream my-app {
        server app:3000;
    }

    upstream web-api {
        server api:18080;
    }

    server {
        listen 443 ssl;
        server_name server-app;
        location / {
            include     /etc/nginx/common_proxy.conf;
            proxy_pass  http://my-app;
        }
    }

    server {
        listen 8443 ssl;
        server_name server-api;
        location / {
            include     /etc/nginx/common_proxy.conf;
            proxy_pass  http://web-api;
        }
    }
}

仲の良い焼き鳥屋さんで軽く飲んできた。2時に寝て7時に起きた。午前中はだらだらしてた。午後から会社の事務手続きをやりながら、実家の法事の段取りをやりながら、ブログの記事などを読んでいた。

jj

茉莉花 (ジャスミン焼酎) をジャスミン茶で割った飲みものを jj と呼ぶらしい。焼き鳥屋さんのマスター曰く、お客さんが 串カツ田中で販売 しているのをみて、焼き鳥屋さんでも扱ってよと言うから置いてみたと話していた。あまりこれまで飲んだことのない不思議な飲みものになっていた。基本はジャスミン茶なんだけど、アルコール入っているなという雰囲気がするカルイ飲みものに感じた。お茶ベースだからどんな食べものにもあいそう。すごくおいしいものではない分、軽く飲みたいときにちょうどいいかもしれない。

法事の出席者管理

来週は35日の だんご転がし がある。2月の上旬には49日もある。過去の葬儀もあわせて親戚や関係者の、出席を管理するためのスプレッドシートを作った。出席確認を母に任せていたらなかなか進まなくてお正月から2週間あってもまだ確認を取り切れていない。人間を調整するのがもっとも面倒で時間がかかる。その後に初盆、1回忌、3回忌と続く。連絡先の電話番号も私の方で管理して、私が電話していった方がよいのかなぁ。

Java は死んだ

• Java is Dead — 5 Misconceptions of developers that still think Java is relevant today!

この記事の著者はいまも java が通用すると思っているとしたらそれは誤解があるという。その誤解を5つあげるといった記事。

誤解1: Javaには、大規模で活発な開発者コミュニティーがある。

これは誤解ではなく事実だと書いてある (´・ω・｀) 著者の意見としては、他言語の進化が速く java は冗長で古い型システムで時代遅れみたいなことを主張している。私の意見だと java の進化もいまは速くていうほど時代遅れというほどではない。過去の資産がいまの java に追いつけていないといったのもある。十分に他言語に機能的に追いついているし開発サイクルも速い。

誤解2: Javaは幅広い用途に使われる。Javaは単なるWeb開発言語ではなく、モバイルアプリやゲーム、エンタープライズレベルのソフトウェアの開発にも利用されている。

これも著者の視点が適切ではない。モバイルでは kotlin が席巻していて、web の開発言語としても java をあげるのは大企業やエンタープライズ開発のみではないかと説いている。たしかに kotlin は java ではないが、jvm 言語ではあるので jvm は未だに必要とされているという事実がある。もう1つ、java はエンタープライズレベルのでミドルウェアで確固とした地位を気付いている。例えば、cassandra, hadoop, kafka など、これらを web 開発で使っている限り、それは web 開発でも使われていると言えるだろう。

誤解3: Javaは基礎となる言語である。多くの新しいプログラミング言語は、Javaの原理と概念に基づいて構築されており、何らかの形でJavaと互換性を持つように設計されている。

こんなこと誰も言っていないと思うけど、著者がそもそも誤解しているのではないか。一方でクリーンアーキテクチャに代表されるような、java のエコシステムで開発されたアーキテクチャなどは java と相性がよい。java と他言語との最大の違いはクラスがないとプログラミングできないという点であり、これはメリット・デメリットをもたらすが、oop においては di 技術を進化させてクリーンアーキテクチャのような概念の下支えをしている。

誤解4: Javaは大手企業の強力なサポートがある。Javaを保守・サポートしているオラクル社は、Javaという言語に強いこだわりを持っており、その開発・改良に投資を続けている。また、GoogleやAmazonなど、多くの大手企業が自社の製品やサービスにJavaを採用している。

oracle という企業とそのプロダクトが市場でのシェアを失っているという視点で懸念を表明している。たしかに oracle はそうかもしれないが、google や amazon だって java を活用しているので oracle がダメになっても web 系の大企業がサポートしていくのではないかと私は推測する。

誤解5: Javaは学校や大学で広く教えられている。

この点だけは著者の意見に違和感はない。一昔前は java が大学でよく教えられていたと思うが、今後は python や go といった、他の言語が最初に学ぶプログラミング言語として人気を博していくのではないかと私も思う。

ざっと読んでみて java 開発をやったことのない経験が浅い開発者が書いた記事だなと思えた。

1時に寝て7時に起きた。なんか微妙な疲れがある。

ストレッチ

今日の開脚幅は開始前155cmで、ストレッチ後159cmだった。先週と同じか。腰に張りは残っているものの、先週のような疲労が蓄積して大変な状況からは脱した。先週に引き続き、ふくらはぎの後ろ筋肉のストレッチを受けているとかなり辛い。プロのトレーナーさんなのでこれ以上は耐えられないという一歩手前のところでコントロールしている。もうちょっと続けられたらもう無理の少し手前で終わるのでなんとか耐えられている。経験上、ストレッチが痛いときほど状態が悪いという警告だと理解しているのでそれはそれで自分の体調がわかってよい。

納車

先日 購入した社用車 が納車された。年明けの出張前に駐車場の手続きをうまくやったので車庫証明も車検も段取りがうまく進み2週間で納車となった。午後から引き取りに行ってきた。いくつかの書類に署名をして印鑑を押して車の操作の説明を受けた。初めてレンタカーを借りるときにも戸惑ったが、いまは車の鍵ではなく、電子キーになっていて勝手にロックが空いたり、エンジンをかけるのも鍵をまわすのではなくボタンを押すといった仕様になっている。他にもハンドル周りにボタンがあったり、ナビゲーターのモニターにもボタンがあったりで使い方を教えてもらった。運転中は不可だが、ワンセグも入るのでテレビもみれるという。あとスマートフォンと bluetooth 接続できる。iphone なら apple music で音楽を聞いたりできる。まだ試したことはないけど、電話もできるらしい。2015年モデルの中古車でもそのぐらいの設備が付いている。ドライブレコーダーも付いていて標準のものではないので前の所有者が取り付けたものを外さずに下取りに出したと推測されるとのこと。私はまったくこだわりはないので付いているならそのまま使えばいいやって感じでラッキーに思えた。

車両状態証明書 によると総合評価点は2と高くはない。機能、内装、走行は問題ない。これは外装にいくつか擦り傷やへこみがあるためにそういった評価になっている。ただ普通にパッと見てわかる擦り傷は1箇所だけで十分にきれいにみえる。外装に擦り傷が多いために総合評価点が低く、年式が新しく走行距離も少ないにも関わらず車両価格が割安であった。そこに私のような、初めて購入して乗る車はきっとぶつけたり擦ったりする確率が高いだろうと想定しているためにまったく気にしない人間とウマがあった。

せっかくなので慣らし運転に行こうと思ってディーラーの営業さんと話していたら 西宮神社 へ行くお客さんが多いという。えべっさんと言えば商売繁盛で有名な神様だけど、交通安全祈願のお祓いもやってくれるみたい。お祓いまではお願いしなかったけど、三ノ宮から10kmぐらいの距離で20-30分もあれば行けるのでちょうどよい距離だった。お参りして交通安全のお守りを買ってきた。