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分もあれば行けるのでちょうどよい距離だった。お参りして交通安全のお守りを買ってきた。

1時に寝て2時、3時、6時と起きて7時に起きた。久しぶりに胃酸が逆流して気分悪かった。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。sveltekit アプリで使う ui フレームワークの相談をして、昨日の課題管理の雑談内容 からさらに考察を深めた。私の中では知っていたことだったはずなのに、いつの間にか、そのことを軽視してしまっていることを再認識したような発見だった。

コミュ障の私にとってはペアワークという概念がすっぽり抜けていたことは昨日書いた通りだが、それでもいまマネージャーとしてそれなりにコードレビューやインフラタスクに時間を割いている。プロジェクトマネジメントだけをやっているわけではない。それは自分が遊撃として開発者のメンバーを手伝っていることに相当するなと気付いて、そう言えば、過去に五月雨式にだらだらと遅れるようなプロジェクトでは、他のメンバーのタスクが遅れることを横からみているだけしかやってなかったような気がした。もし私が自分のタスクを投げ出して遅れている課題に介入したらどうなっただろうか？と思考実験するだけの余地はあった。

もう1つ。盛り上がった話しにおっさんはエモい話しをしにくいと私が考えていると伝えた。なぜなら、私の経験則ではエモい話しをするおっさんは総じてスキルをもっていなかった。具体的な知識やプラクティスを話すときはエモい話にならないからだ。その発言に対して、はらさんからはこんなコメントが返ってきた。おっさんもスキルはあるのだけど、そのスキルが時代にあわなくなって古くなってしまった。現場の技術とあわないスキルは、現場の人間からみるとスキルがない人と同じである。少し前に40歳の壁という本を読んだが、そのノリで言うと、40歳になるとスキルが現場に通じなくなる。

いまマネージャーをしていて気付かないうちに遊撃というポジションをこなしているのではないかと思うようになってきた。原則として実務をやらず、プロジェクトマネジメントをしている。とはいえ、コードレビューには2-3日／週ぐらいの工数を割いてきた。

— Tetsuya Morimoto (@t2y) January 21, 2023

sveltekit アプリのデプロイ

昨日の続き。Building your app によると、sveltekit のビルドは vite と adapter の2段階で行われる。gitlab ci/cd で node.js 向けにビルドして、それを docker イメージに同梱して、コンテナレジストリに登録する。あとはテスト環境で構築している docker compose に組み込むだけ。今日中にできたらいいなと思って、ぎりぎりだったけど、テスト環境で node.js 上にデプロイしたアプリと疎通できるところまでできた。ssr を介して web api サーバーと疎通できるところまで整備した。ここから先はメンバーに管理画面を作っていってもらう。メンバーの開発着手前にデプロイが一通りできているという気持ちよさ。

起業相談

過去に働いていた会社の、私と同い年の元同僚が起業するというので相談にのることに。私が会社を作ってなんとかやっているのをみて関心が出てきたという。いきなり会社を辞めると不安だから副業から始めて、本業の収入を上回るようになったから個人事業主から法人化しようと考えているらしい。実際に会社を辞めるかどうかはまだこれから検討するのかな？本業をやりながら最大4つか5つの副業をまわしてたというから驚き。そんなこと物理的に可能なの？と思ったら開発は人を雇ってマネジメントだけやったりしていたらしい。おそらく4人ぐらい開発者を雇っているという雰囲気だったけど、それでも本業をやりながら4つもマネジメントをするのは相当に大変だと思う。十分にその同僚の能力を認めているつもりだったけれど、それ以上の忍耐や集中力をもっていて、もしかしたら過小評価していたのかもしれない。1つの会社内でも3つ以上プロジェクトを兼任して成果を出しているマネージャーなんか私は見たことない。それを本業と副業と寄せ集めの開発者で実現しているのは類稀な能力だと思う。本人も睡眠時間削って働いてやり過ぎたとは言っていたが。法人登記、税金、節税、働き方とか、ざっくばらんに私が起業してやってきた3年間のお話しをした。なにかしら役に立って活躍されるといいな。

2時に寝て7時に起きた。キングダムの新刊を読みながら寝てた。

sveltekit の初期プロジェクト

技術選定で svelte を採用した ので昨日から SvelteKit でアプリケーション開発に着手した。Project structure にもだいぶ慣れてきた。開発初期はディレクトリ構成に迷うのでドキュメントに標準的な階層構造を書いてくれているのは素晴らしい。Routing もキモいけど、ssr の場合は +page.svelte と +page.server.ts を設けるのに慣れてきた。ssr で proxy 的に web api 呼び出しも簡単に実装した。知らないフレームワークで開発するのは学ぶところが多くて楽しい。区切りのよいところで初期開発の issue はクローズして明日は gitlab ci/cd でテスト環境にデプロイするのをやってみる。

課題管理の雑談

過去に働いていた会社の同僚と課題管理について雑談した。web3 系の会社で働いているのでブロックチェーンや dao 周りの話しも一緒にしたりしていた。一回りぐらい私より若いと思うけれど、私よりはるかに優秀な開発者だなぁと感じながら話しを聞いていた。いま一緒に働いても足手まといになるんじゃないかと思えて身が引き締まる。いくつか話題の中で学んだことを抜き出してみる。

• 自分の知識やスキルを共有する手段の1つとしてペアワークをやる
  • ペアワークを通してメンバーとの信頼関係も構築していく
  • いまもっている知識やスキルには個人差はあるが、模倣の能力が低い人をみたことがない
• 上位の意思決定者から低いレベルにあわせる (標準化など) ように指示がきたときは反発する
  • ユーザーファーストが第一ならレベルを下げるような指示はおかしい
  • 「誰を向いて仕事しているの？」と説得する
• プロジェクトにおいて目的を明確化せずに始めてしまうのは本当によくない
  • 日本人は上意下達で行動するように教育されてきた弊害ではないか
  • 目的を明確化するのは意見を言うことと同じである
    • レイヤーが上がるほどエモい話しになって人生観や哲学の話しになっていく
    • チームのモチベーションを維持する上でも有効ではないか

私はコミュ障だから他人と一緒に作業しようという発想がそもそもなかった。こちらから一緒にやろうと声をかけて知識やスキルを共有する手段もあるのかと気付いた。これまでも何人もの人にいろんな話しを伺っている。他人のノウハウを聞くだけでもこの雑談をすることに意味はあると思えた。

0時に寝て7時に起きた。最近はよく眠れるようになってきた。

日銀会合の結果

12時から 1on1 だったのでずっとみていたわけじゃないけど、12時前チェックしたら為替が円安に触れていたので現状維持なことが伺えた。業務を終えてから後藤さんの記事も拝見した。YCC はいずれ修正されるので近い将来に金利が上がることはわかっているが、そのときに市場が動揺して急激な円高になってしまうようなことは経済にとってよくないとのこと。本来はそういうことが起こらないように中央銀行と市場が丁寧に対話を重ねるものだという。いまの日銀の雰囲気だと、3月か4月に急激な形で訪れるかもしれないといった懸念があるように伺えた。

• 【速報】日銀会合 スピード解説

後藤さんが質問しているところだけでもみようと思ってみた。のらりくらりとかわされてしまったとのこと。

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。メンバーの1人が ジモティー でイベントするのが熱いという話題がおもしろかった。ジモティーって中古品の売買するプラットフォームじゃないの？とみんな思ってたら、最近はイベントなんかもできるようになっていて、ユーザーが多いのにあまりイベント開催に使っている人がいないから狙い目だという。へーと思って、私もスマホにジモティーをインストールしてどんな雰囲気か眺めてみた。ざっとみたら婚活イベントが多くてうんざりしたが。

コワーキングスペースのイベント管理プラットフォームの開発を進めているらしい。日本にはコワーキングスペース向けのプラットフォームというのが存在しないからチャンスはあるのだと思う。これまでなかったのはコワーキングスペースという市場が小さ過ぎて儲からないから誰も参入しようとしていないだけでしょうというのは納得感がある。さらに私からみると、すでに世の中に sns や無料のプラットフォームがたくさんある中で、わざわざコワーキングスペース向けのツールが必要なのかどうか、需要のところでどうなんだろう？という懸念はある。これからクラウドファウンディングなども予定しているそうでそれが公開されたら、私も (会社として) お世話になっているから少しくらい寄付しようかと思う。この場合は会社間の付き合いとも受け取れるから協賛金として会計処理してよいはず。

1時に寝て7時に起きた。なんか朝うまく起きれなくなってきた。なんでだろう？

svelte アプリの開発に着手

12月の1週間分ぐらいの工数をかけて行っていた フロントエンドの技術選定 の意志決定をした、というよりはしてもらった。私は調査結果をまとめ、react を選択しても svelte を選択しても開発視点ではどちらも同じという判断を下した。あとはお手伝い先の会社にとってどちらの技術に取り組みたいかという視点しかないなと考えて CTO に最終決断を委ねた。その結果 svelte を採用することに決まった。この調査や意志決定についていずれテックブログに書きたい。私がどのぐらい開発に参加するかはまだ未定だけど、初期のリポジトリの整理ぐらいはしておこうと svelte アプリ開発に着手した。初めて関わる技術はなんにせよおもしろい。お仕事で学びがあれば個人でもなにかしら svelte アプリを作ってみたい。

java の ldap クライアント

昨日のコードリーディングの続き。いま使っているライブラリは Apache Directory LDAP API というものだけど、このライブラリの設計があまりイケてない。古い java の考え方で設計されているライブラリのような印象を受けた。他にも java の ldap クライアントはないのかな？と調べたら so でちょうど議論されていた。

• Java API to query LDAP

この so によると、UnboundID LDAP SDK for Java がベストアンサーになっている。また機会があれば触ってみようかなと思った。

2時に寝て7時半に起きた。ちょっと生活が乱れ気味。

コードリーディングの準備

tenntenn さんの コードリーディングをしよう #tennconn のやり方を参考に、コードリーディングの勉強会を行うことにした。ある4つのプログラムがあって実績もあるという話しなので基本的には既存のコードがどのように動いているのかをメンバーみんなで確認しておこうといったもの。その段取りを決めたり、日程のスケジュールを調整したり、基本的にはイベント当日にソースを読むようにして準備の負担を少なくする一方、私が一番既存のコードを知らないので事前にソースを読んでおこうとリポジトリを眺めていた。

インフレ勉強会

エンジニアのためのインフレ研究会 #2 に参加した。この火曜日・水曜日の2日間に渡って開催される日銀会合に注目が集まっているという話題があった。議論に揉めたりしなかったら正午前に会合の結果がすぐ公表されるが、政策変更があるときは発表が遅れる傾向にあって発表時間が早い・遅いでも結果を予測して為替などが動くらしい。後藤さんの記事でも同じようなことが書いてあった。これまで日銀会合なんて気にしたことはなかったけど、政策変更の可能性があるかも？と言われるとへーと思って注目してみようと思う。こういう関心をもつ機会が増えると経済を学ぶきっかけになるかもしれない。

• 日銀会合 発表時刻も要注目

20時ぐらいからだらだらしていて寝たり起きたりしていた。9時に起きた。バテてたからちょうど休養になった。

散髪

年末に行こうと思っていたのが葬儀で予定が狂ってしまってその後も会社の事務手続きや社用車の購入にバタバタして出張があって今日行ってこれた。いつも散髪に行って思うことはもっと早く行けばよかったということ。散髪を終えた後の髪の鬱陶しさから解放されて楽に感じる。もう一定の髪量になったら私のカレンダーの空いている時間帯を見繕って自動的に散髪屋さんに予約をとってほしいとすら思える。カメラとカレンダーを組み合わせてそういったワークフローを作ること自体はできるかもしれない。

日記

出張していたときの日記をまとめて推敲してアップロードした。なんか出張すると、夜はお出かけして遊んでたり、ホテルに戻ってからもだらだらして日記を書かないことが多い。原因の1つにホテルの部屋の椅子がオフィスにあるものと比べてよくない。疲れて帰ってきて、オフィスよりも椅子の悪いところで日記を書く気になれないというのがある。アーロンチェアに慣れてしまってこの椅子で書きものをするのが快適過ぎて、他の環境で書くのをためらってしまう自分がいる。アーロンチェアは半日以上書きものしていても全然疲れない。

フリーランス、４０歳の壁

早いうちの方が覚えているからよいだろうとエイヤで書いてみた。読み終えた後にあまり思い入れもなかったので書評も簡潔なものとなった。まぁまぁの手応え。

• フリーランス、４０歳の壁の書評