Posts for: #2023/03

chatgpt の調べものと整理して雑談した

1時に寝て6時に起きた。昨日は chatgpt の調べものをしていたら帰るのが遅くなった。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。3月はお仕事が忙しかったのでこの前はお休みして1ヶ月ぶりの雑談。主には 来季の予算 について話していた。

予算を策定するときに今回から消費税を経費に含めるとよいのではないかと考えた。というのは、法人税は赤字のときにゼロになるので売上と経費を算定したときに利益が多ければ発生するだけで利益を帳消しにするといったことはない。しかし、消費税は損益に関係なく仕入よりも売上にかかる消費税が多い場合に支払う必要がある。ここで経費の大半に相当する人件費 (給与) には消費税がかからないことから損益がゼロだったとしても消費税を支払うと赤字になるといった状況は考えられる。売上よりも仕入で支払った消費税の方が多かった場合、消費税は還付されることになるが、うちは簡易課税を選択しているので売上の消費税に対して50%を支払うことになる。簡易課税の場合、最小の消費税がゼロ (つまり売上がゼロ) であり、仕入にどれだけ消費税を支払ったとしても還付は発生しない。とはいえ、通常の事業運営をすれば仕入の消費税が売上よりも多くなるといったことは発生しない。

オフィス引越しや社用車の購入に関して前年よりも固定費は増えている。それは仕方ないとして、その他に無駄遣いをしているわけでもないので来季は赤字前提の予算を見積もる。いまのところ、お仕事は半年ぐらいしかやらない予定になる。仮にそれ以上働くことになったとしても、そのときは売上が増えて財務的には助かることになる。お仕事があってもなくてもどちらでもよいという展望で予算策定を終えた。

社員数を調べるハック

たまたまタイムラインで 厚生年金保険・健康保険 適用事業所検索システム というシステムで毎月20日時点での厚生年金保険・健康保険の被保険者数を調べられることを知った。未上場の会社だと社員数を公表する義務がないので規模感が分からないことがある。スタートアップやベンチャー企業で話題になっている会社の規模感を調べるときなどに役に立つかもしれない。試しに過去に私が働いた会社でその後どうなったのだろう?と調べてみたら私が在籍していた当時よりも人数は減っているもののまだ被保険者数がいたので会社は存続していることがわかった。会社の栄枯盛衰を測る指標の1つとして社員数は使えると思うので業界研究の手法の1つとしてよいかもしれない。

chatgpt 勉強会

今週のチーム勉強会は私が担当して chatgpt についての雑談会とした。と言っても、ほとんど私が一方的に話す感じであまり雑談会にはならなかった。オンライン勉強会で雑談会を運営するのはすごく難しい。意図的に質問やツッコミを入れるという役割を参加者に課さないと雑談会を運営するのは難しいのかもしれない。勉強会で発表すると、自分で学ぶきっかけになるのでちょうどよかった。お手伝い先でも slack に chatgpt の api を用いた bot を実装してチャットで質問できるようになっている。何人かは身近に chatgpt を使って振る舞いを確認したりもしている。雑談会では次の内容で gpt (llm) とはどういうものなのか、また chatgpt の使い方が従来にはなかったものを私が知っている中で共有した。今後もしばらくは注目していこうと思う。

  • OpenAI/ChatGPT 概要
  • ChatGPT の使い方
  • GPT 以後の世界

コンテナレジストリをプライベートに運用する

0時に寝て7時に起きた。晩ご飯を食べきれなくて調子悪いと思っていたら夜も吐き気と胃酸で気分が悪くてあまり眠れなかった。

外部向けコンテナレジストリ

いまお仕事で作っているアプリケーションは docker image としてパッケージングしている。エンドユーザーがこのアプリケーションを使うためには docker pull できるためにインターネットを経由してアクセスできる必要がある。普段はイントラネットのコンテナレジストリに push/pull して運用しているのを、外部のエンドユーザー向けにアクセスできるコンテナレジストリ (リポジトリ) を構築しないといけない。パブリックなリポジトリとして提供するのであれば、docker hubGitHub Container registry などを無料で利用できる。しかし、プライベートなリポジトリで運用しようとするとその選択肢は狭まってしまう。おそらく他社のサービスを使うのであれば、実際の運用を考慮するといくらか費用がかかるだろう。

仮に docker image が使うストレージを5GiB、インターネットへの outbound なデータ転送を30GiB/月で見積もってみた。docker hub だと利用量によって課金されないのでその後に利用増加が前提であればよさそうにみえる。

  • github (従量課金)

  • aws (従量課金)

    • region=tokyo: $3.92/month, $47.04/year
  • docker hub (容量無制限)

別の選択肢として自前でコンテナレジストリを運用するという方法もある。docker registry サーバーは oss として公開されていて docker image の push/pull をするだけのサーバーならすぐに構築できる。ベーシック認証に近い v1 の認証でよければ htpasswd を使ってアカウント管理できる。

ドメインと tls の証明書と外部からアクセスできるサーバーがあれば、自前で運用するのもそう大変ではないと思う。実際にこれらの運用コストと他サービスの利用料金とを比べて選択することになるだろう。

gitlab packages api の使い方

0時に寝て何度か起きて6時半に起きた。先週より少し早く起きれるようになってきた。

gitlab ci/cd で別プロジェクト (リポジトリ) の成果物を取得する

gitlab では複数のパッケージリポジトリに対応しているが、それらに当てはまらない汎用の成果物向けに GitLab Generic Packages Repository というものがある。zip でもバイナリファイルでも何でも置くためのリポジトリと言える。但し、同じパッケージ名でバージョン管理するといった作りにはなっていなくて、同じパッケージ名でアップロードしても別のパッケージ id が割り当てられて管理される。他バージョンとの紐付け自体はできているので、おそらく歴史的経緯でそういう仕様なのだと思う。そのために、あるパッケージの最新のバージョンを取得したいときは作成日の降順でソートして最初のパッケージを取得するといったコードを書かないといけない。それは Packages API を駆使して簡単なスクリプトを書くことになる。

もう1つ分からないことにトークンの使い分けがある。なるべく ci/cd での処理は GitLab CI/CD job token を使いたいところだが、どうも Packages API の呼び出しはできなくて別途プロジェクトでアクセストークンを作成して呼び出すようにしている。これはもしかしたら別の設定で CI/CD job token でも呼び出しできるかもしれない。rest api への呼び出し権限そのものがないのかもしれない。

最終的には次のようなスクリプトで任意のプロジェクトの generic リポジトリの最新の成果物を取得できた。

rm -rf ${TARGET_DIR}
mkdir -p ${TARGET_DIR}
for project in $PROJECTS
do
  prj=$(echo "$project" | jq -Rr @uri)
  base="${CI_API_V4_URL}/projects/${prj}"
  pkg=$(curl -s -H "PRIVATE-TOKEN: $PROJECT_ACCESS_TOKEN" "${base}/packages?order_by=created_at&sort=desc&per_page=1" | jq '.[0]')
  pkg_id=$(echo $pkg | jq -r .id)
  pkg_name=$(echo $pkg | jq -r .name)
  pkg_version=$(echo $pkg | jq -r .version)
  file_names=$(curl -s -H "PRIVATE-TOKEN: $PROJECT_ACCESS_TOKEN" "${base}/packages/${pkg_id}/package_files" | jq -r '.[].file_name')
  for file_name in $file_names
  do
    dw_endpoint="${base}/packages/generic/${pkg_name}/${pkg_version}/${file_name}"
    curl -s -H "PRIVATE-TOKEN: $PROJECT_ACCESS_TOKEN" "${dw_endpoint}" -o "${TARGET_DIR}/${file_name}"
  done
done
find ${TARGET_DIR} -type f

財布の置き場所を忘れる

3時に寝て7時に起きた。

昨日の夜に リベンジャー の最終回をみてよかった。

週次の定例会議を終えて、テスト環境の再作成を待ったり、compose.yml をデプロイするための rpm のパッケージングするための gitlab ci/cd の rest api などを調べたり、これといって特筆するようなことのない1日だった。

財布を失いかけた

家に帰るときになって財布がないことに気付いた。お昼にお弁当を購入したときに財布を使ったのでお昼まではあった。お弁当を食べるために家に帰ったのでそのときに家に置き忘れたのかな?と思って、一旦家に帰ったけど、財布はない。財布を落としてしまったんだなとがっかりして家とオフィスの道中に財布が落ちていないかを確認しつつ、もう一度オフィスへ戻った。オフィスでも一通り調べていたところ、引き出しの中から出てきた。

お昼にレシートとクレジットカードの明細をホッチキスで閉じるときに引き出しからホッチキスを取り出して、そのときにホッチキスと一緒に財布を引き出しの中にしまっていたようだ。まったく記憶になくて無意識でそうしていた。歳をとるとたまにはそういうことがあるのか、そろそろ認知能力が落ちきているのか、そんなことも起きるんだという失敗談になった。まったく自分が信頼できない。

docker/compose のモジュールの使い方がわかってきた

0時に寝て7時に起きた。前日はバテてだらだらしていたので寝過ぎた。

案ずるよりもツールできた

先週末に docker/compose 関連のライブラリ調査 を終えて実際のツール作りをしていた。本当は日曜日に作ってしまおうと思いつつ休んでしまった。なぜか今日はメンバーが全員お休みでチームで私しか働いていなかった。年度末で有休消化しているのかな?問い合わせ対応やメンバーのサポートが不要だったので1日中、自分の開発に集中できた。そして開発に集中できた結果、一通りツールの機能の開発を終えられた。火曜日までには仕上げたいと思っていたのでぎりぎり間に合った。

最終的に testcontainers-go の compose モジュールを使うのは断念して compose cli のみ go 標準の os/exec パッケージを使ってプロセスを fork するようにした。また docker image をコンテナレジストリから取得するときに認証が必要な場合、最初の docker login すると credentials store にパスワード (またはトークン) 情報が記録される。設定情報は $HOME/.docker/config.json からも確認できる。この仕組みを使ってコンテナレジストリへのログインを自動化できる。私の環境では macbook に docker desktop をインストールしているが、普通に使っていると次のように credentials が保存されてその内容を確認できる。

$ docker-credential-desktop list | jq .
{
  "https://index.docker.io/v1/": "t2y1979",
  "https://index.docker.io/v1/access-token": "t2y1979",
  "https://index.docker.io/v1/refresh-token": "t2y1979"
}
$ echo "https://index.docker.io/v1/access-token" | docker-credential-desktop get
{"ServerURL":"https://index.docker.io/v1/access-token","Username":"t2y1979","Secret":"***"}

これと同じことを docker のライブラリで行うには次のようにする。取得したい docker image の uri を参照すればコンテナレジストリがわかる。そこからこの cli でやっているようなことを順番にやっていけばよい。これらのユーティリティは3つのリポジトリで管理されていて、この雰囲気をみただけでもこのモジュール分割が本当に適切なんやろか?とか思ったりもする。

func getRegistryAuthFromImage(
	ctx context.Context, imageURI string,
) (string, error) {
	ref, err := reference.ParseNormalizedNamed(imageURI)
	if err != nil {
		return "", fmt.Errorf("failed to parse image uri: %w", err)
	}
	repo, err := registry.ParseRepositoryInfo(ref)
	if err != nil {
		return "", fmt.Errorf("failed to parse repository: %w", err)
	}
	dcli, err := command.NewDockerCli()
	if err != nil {
		return "", fmt.Errorf("failed to create docker cli: %w", err)
	}
	auth := command.ResolveAuthConfig(ctx, dcli, repo.Index)
	encoded, err := command.EncodeAuthToBase64(auth)
	if err != nil {
		return "", fmt.Errorf("failed to encode auth: %w", err)
	}
	return encoded, nil
}

春休み 2日目

2週間前に引き続き 今日も春休み。昨日まではお仕事のツール開発をしようと思っていたのだがバテた。

人は変わる

たまたまはてブで 立花さんとの対談について というエントリを読んだ。この記事だけではなんのことかわからないので、川上さんと立花さんの対談の動画を検索してみた。動画は2時間半ぐらいあった。 いや、実際にはみていない。みようとしたが、みる価値がなさそうなので飛ばし飛ばしで15分ぐらいしかみていない。みなくてよいと思う。おっさん同士が並行線のまま口喧嘩しているだけの動画だった。ちゃんとみてないから間違っているかもしれないが。

ニコニコ動画が youtube と競っていた頃、2012年頃かな?それぐらいの時期のときにニコニコ動画を応援していたし、そのときに川上さんは時代の寵児のようにみえた。川上さんの対談や記事をたくさん読んだし、著書である コンテンツの秘密 も素晴らしい本だと思う。ある時からなんか時代にあわない発言をされるように感じていた。カドカワの後継者になって身の丈を超えてしまったのか、インターネット規制の議論で体制側になってしまったからなのか、私の価値観の方向性とはあわなくなってしまった。最近はあまり活躍をみないと思っていて、たまたまみたものが口喧嘩の動画でさらにがっかりした。

過去に偉大な実績を残された方が歳を経て退化するような現象は他にもいくつかある。自分が周りからみてどのようにみえているか、私にはわからないが、謙虚に真摯に目の前のことに向き合って取り組むようにしたい。相手に敬意をもって接するといった当たり前のことができなくならないよう、気をつけたいと思えた。

ubuntu のインストール

1時に寝て5時に起きて7時に起きた。今週も開発に集中していたのでバテ気味。時間がなくて2ヶ月以上行ってなかった散髪に行ってきた。前髪が目にかかって鬱陶しかったのでいつもよりも短くしてもらった。頭が軽いと日々の生活のストレスも軽減しそう。

ストレッチ

今日の開脚幅は開始前153cmで、ストレッチ後153cmだった。ストレッチ後の開脚幅はいつもとは計り方を変えたので数値は低くなっているが普段と同じぐらいのものだろう。すねの外側の筋は気にならないぐらいになったので復調したと言っていいだろう。今日は右股関節から太ももにかけての張りと右腰の張りが大きかった。今週も根を詰めて長時間オフィスで作業していたので座っているとかかる部位の負荷が高くなっていると想定される。納期が4月末なのでこの生活はもうしばらく続くといったところ。

dell マシンに ubuntu をインストール

いつも通りオフィスで会社の事務手続きをしながら、並行して 購入した dell マシン に ubuntu をインストールする。いまお仕事で開発しているアプリケーションの成果物は amd64 をターゲットにしているのでローカルに amd64 の開発環境がないとインフラ周りやコンテナ周りの検証に一手間かかる。この状況を解消するために早くローカルの dell マシンを置き換えて開発環境を構築したい。dvd-r から ubuntu 22.04.01 (サイズ超過で dvd-r におさまらなくて 22.04.02 は断念) のインストールを行う。bios で一時的に secure boot の機能を無効にしないと署名チェックで起動しなかった。インストール作業中に予期せぬ不具合が発生しました的なポップアップが2-3回発生したけど、無視して継続できた。インストールして普通に起動すればいいやと緩い感覚で進めた。いつもはパーティションも自分で設定したりしているけれど、今回は windows 領域を残してデュアルブートな環境にしてみた。ディスク領域もインストーラーから windows 領域を 160GiB、残りをすべて ubuntu 領域にするといった設定ができた。すごい簡単。余裕があるときに windows の wsl を使うのも試してみれればと思う。

コンテナの運用ツールを作る

1時に寝て明け方に起きて7時に起きた。あまり眠れてない雰囲気がある。

docker/compose の運用

いま作っているアプリケーションは docker compose で構成している。マージ単位で gitlab ci/cd から docker image をビルドしていて、テスト環境のデプロイスクリプトで最新の docker image を取得してコンテナを再作成するようにしている。デプロイスクリプトは docker cli と docker compose cli の2つを組み合わせてシェルスクリプトで実装しているが、複数のアプリケーションやミドルウェアがあるのでそれらを統合的に扱うことはできないし、さまざまな状況を想定して動くようにもなっていない。がんばれば doccker/compose cli と jq とシェルスクリプトで細かい要件を実装することもできるけど、それをお客さんの本番環境においても使うには一定の cli 操作に慣れが必要な上、docker/compose の知識やスキルも要求してしまう。少なくとも頻繁にある運用作業として docker image の更新やコンテナの再作成が想定される。ローリングアップデートまでは実装しないけど、アプリケーションの要件にあわせた docker image の更新とコンテナの再作成 (アプリケーションの再起動) ぐらいはまとめてやってしまってよいと思う。

github.com/docker/docker は github.com/moby/moby にリダイレクトされる。docker は開発ツール、moby はインフラやライブラリという住み分けでそれぞれに関心のあることに注力するようにモジュール構成を分離している。それが2019年に行われていまもおそらくまだ途上だと思う。あと docker のモジュール群は go modules に対応していない。大きなプロジェクトが移行するのが大変なのは理解できるけれど、依存解決のような複雑なところを放置するのはまったく賛成できない。そこが不健全だと依存ライブラリの整理やモジュール分割がうまく進まない気がする。docker の client は https://github.com/moby/moby/tree/master/client に定義されていて、readme のサンプルコードにあるようにすぐに使えるようになっている。一方で compose の spec は github.com/compose-spec/compose-go で定義されていて、github.com/docker/compose はまだライブラリとして使いやすいようにはなっていない。仕様と実装が混在していて動いている状態。そういう issue もあげられている。

testcontainers-go というアプリケーションが compose をライブラリとして使う実装をしている。このコードをみれば compose をどう使えばよいのかはわかる。

自分で compose を実装してもよいけれど、compose の service を扱うための project やオプションの設定が煩雑なことも伺える。仕様と実装が混在しているというのはそこら変の整理ができていないようにみえるからだ。testcontainers-go も自前の client を用意して使いやすいようにしているのでそれを再利用した方が運用ツールを作るのは簡単になる。testcontainers-go の compose client 経由で compose の up/down を制御する。その他のコンテナの操作は docker client を直接使って実装する。この組み合わせで自分たちのアプリケーション向けの運用ツールを作ろうと思う。

デスクトップマシンの買い替え

1時に寝て5時に起きて7時に起きた。昨日も吐き気がしてうまく眠れなかった。

dell マシンの買い替え

1月頃からデスクトップマシンの調子が悪かった 。ちょうど3年経ったところでそろそろ故障してもおかしくないと言える。ちょうど年度末なので dell の半期に一度の大感謝祭を待って購入することにした。これまでは vostro を使っていた。そろそろメモリが16GiBだと厳しくなってきたところ。メモリが32GiBついているデスクトップマシンは限られてくる。 その制約もあって xps マシンを購入をすることにした。

昨日のお昼過ぎに注文したのに翌日の午前中にマシンが届いた。あまりの早さに驚いた。dell の配送のワークフローの凄さを実感した。デスクトップマシンを注文して1週間ぐらいで来たらいいと普通の感覚で思っていたら翌日なんやもんな。24時間も経ってなかったしな。

グラフィックボードからモニタに接続しようとしたら4つのインターフェースのうち3つが displayport で1つが hdmi になっていた。いまどきは displayport が主流なんやね。そんなことすらも知らなくて変換アダプタ買わないととか思っていたら、モニターも displayport をもっていて、モニターの箱にも displayport ケーブルが同梱されていて、そのまま接続できることに気付いた。3年ぐらいでマシンを買い替えないとハードウェアのデバイスの変更にもついていけないのだなということも実感した。

私はもう世の中についていけてなくて、たまに普段やらないことをやるとそこで起きることに驚いて右往左往している。windows を起動して dell update から bios やファームウェアを最新のもの更新したりしていた。windows 上からダウンロードして設定して、再起動時に自動的に bios の更新がかかるような振る舞いをする。uefi のなせる技なんだろうけど、こういうところにも驚いて感心したりする。

ubuntu 22.04.02 が 4.8GiB あって dvd-r にぎりぎりおさまらない。もう dvd-r でもインストールメディアを作ることができなくなったんやなと気付く。22.04.01 は 3.6 GiB なので1つ前のバージョンをインストールしてアップグレードすればいいかとやってみたらブート時に次のようなエラーになった。

Verification failed:(0x1A) Security Violation

bios に secure boot 機能なるものがあって 22.04.01 ではインストールできないように署名チェックが行われるらしい。古いディストリビューションをインストールするには secure boot を一時的に無効にするしかなさそう。

プライベートリポジトリの go アプリケーションの依存解決

0時に寝て6時半に起きた。面倒なお仕事を朝から集中して片づけた。

go.mod のプライベートリポジトリの依存解決

非公開のプライベートリポジトリで開発している go アプリケーションを他のリポジトリから依存ライブラリとして使う方法を調べた。go modules は基本的に公開されたパブリックなリポジトリを前提としている。go.mod のワークフローで他の依存ライブラリと同様にバージョン管理ができるようにするには、プライベートリポジトリであることを go.mod に認識させ、トークンなどを使って認証する必要がある。

go 1.13 から GOPROXYGOPRIVATE という環境変数が追加された。デフォルトでは GOPROXY は https://proxy.golang.org に設定されており、このプロキシサーバー経由で依存ライブラリを取得する。これは公開リポジトリを、ある日、作者が急に削除したり非公開にしたときにビルドできないといった問題を防ぐために依存ライブラリのリポジトリをキャッシュしてくれる役割を担っている。

一方でインターネット上のプロキシサーバーからはプライベートリポジトリへアクセスできないので GOPRIVATE を設定してアクセスできないサイトを go.mod へ教えてあげる必要がある。

$ go env -w GOPRIVATE="private.repo.jp"
$ go env | grep GOPRIVATE
GOPRIVATE="private.repo.jp"

通常 go.mod は https で依存ライブラリをリポジトリから取得 (クローン) しようとする。このときに git の設定を変更することで特定のサイトへのアクセスを ssh 経由に変更できる。次の例では https://private.repo.jp へのアクセスをすべて ssh://git@private.repo.jp でクローンできる。

$ git config --global url."ssh://git@private.repo.jp".insteadOf "https://private.repo.jp"`
$ tail -n 2 ~/.gitconfig
[url "ssh://git@gitlab.osstech.co.jp"]
        insteadOf = https://gitlab.osstech.co.jp

これで git リポジトリのクローンは ssh で行われるようになるが、go.mod のワークフローでは https でもアクセスする処理があるようにみえる。https でもアクセスできるように PAT などのトークンを取得して次のように ~/.netrc に https でプライベートリポジトリへアクセスするための認証設定を追加する。

machine private.repo.jp
login t2y 
password ${PERSONAL_ACCESS_TOKEN}

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

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。いとうさんの近況を把握していないが、どうやらバリ島 (インドネシア) のコワーキングスペースをいくつか訪問してきたらしい。その旅程を写真をみながらふりかえるようなイベントだった。バリ島の自然や建物の雰囲気が伺えてとてもおもしろかった。

いとうさんからバリ島はデジタルノマドの先進的な取り組みをしているように聞いていた。例えば バリ島でリモートも可能!?インドネシアのノマドビザは最長5年を検討中 にあるように最長5年のビザを用意しているという話しが日本で盛り上がっているが、現地ではまだ正式にそのようなビザがあるようには存在が確認されていないらしい。それに近い長期のビザを取得するには、一定の金融資産があることを証明しないといけないらしく、日本円だと数千万円程度ないとビザを取得できないのではないか?といった話題もあったと思う。基本的にインドネシア政府は海外から金持ちを呼び込みたいらしく、金持ち向けに待遇のよいビザを整備するのではないかとのこと。ビザの話しはともかく、ここ2-3年でバリ島のコワーキングスペースもいくつか廃業しているらしい。それは利用者の大半が外国人であったため、コロナ禍により、インドネシア政府からの要請もあって外国人に帰国を促したという。外国人利用者の半分ぐらいが自分たちの国に帰ってしまい、施設の運用コストを維持できなくなった。バリ島は今後の成長が見込まれていることから数年前から外資が入ってきて土地や家賃が急騰しているために利用者が激減すると運用コストを維持できなくなったとのこと。

肝心のバリ島のコワーキングスペースの雰囲気を聞いていると、利用者は外国人が大半で、感覚的にはヨーロッパから来ている人が多そうだといとうさんが話された。バリ島のコワーキングスペースでいとうさんが見学していたときには、現地の人たちと外国人のコミュニティが活発に活動しているようにはあまりみえなかったらしい。利用者もそう多くはなかったし、その人たちも静かにただ作業しているだけのように映ったという。いとうさんはコワーキングスペースとはコミュニティやコラボレーションが重要という話しをよくしているけれど、バリ島のコワーキングスペースに関しては裕福な外国のデジタルノマドを呼び込むのに成功しただけのような、もしかしたらコロナ禍でそのコミュニティが破壊されてしまったのかもしれないが、普段このイベントで話しているような高い期待値に応えられるような状況ではないようにみえたという。

とはいえ、日本の田舎よりは遥かにデジタルノマドが集まる場所として世界的に認知されているところなので写真をみながら私もいつか行ってみたいと思えた。

出張所オフィスの準備

1時に寝て7時に起きて朝だらだらして9時過ぎからオフィスへ行って軽くお仕事をしていた。

駐車場の契約書作成

午前中に駐車場の契約書を作成して送付した。管理会社さんとやり取りしたときに 保管場所使用承諾証明書 を即日作ってくれてスムーズに納車できた。その駐車場の契約書をいま手続きしている。便宜を図ってもらって感謝。週末から車を動かした方がよいなと思いつつ、雨降りでタイミングが悪く出掛けるのに億劫になっている。

ツールの開発とリファクタリング

いつも通り3時間ほどお仕事していた。時間はたった3時間だけど、割り込みが入らないことがわかっているので開発に集中できて生産性は高い。issue を3つほど fix して区切りがよかったので夕方には家に帰ってお昼ご飯を作ってのんびりしていた。

実家の出張所オフィスの準備

親とやり取りしていて、出張所のオフィスとするための部屋にエアコンとインターネットの回線を繋ごうといった話しをしていた。エアコンは14畳のやや大きいものを購入しないといけない。工事に来てもらわないといけないので近所の量販店で信頼できるメーカーの製品を買った方がよいだろうと話していて、いま実家で取り付けしているエアコンのメーカーを聞いたらダイキンだという。日本の会社だったらまぁいっかと思ってダイキンでいいんちゃうと返しておいた。インターネット回線もスマートフォンのキャリアとセットにした方が割引で安くなるからショップ行って聞いてみたら教えてくれるだろうと伝えておいた。これを伝えてから実際に購入するまで何ヶ月かかるのかはわからないが。