Posts for: #Svelte

sveltekit の base path 設定

昨日遅くまで作業していたせいか、体調があまりよくなくて19時でお仕事を終えて帰って休んでいた。21時過ぎにはベッドに入って寝てた。

base path 移行とビルド

リバースプロキシのルーティング検証 を終えて path based routing を採用することに決まった。そのため、nginx の設定にあわせて sveltekit の ui の base path を設定し直し、テスト環境にデプロイして検証していた。デプロイ先の制約によって base path が変わるというのはよくある状況なので sveltekit も Configuration pathssvelte.config.js に base path が設定できるようになっている。当初は環境変数で切り替えできるように設定して修正したものの、実際にビルドしてコンテナでテスト環境へデプロイしてみると有効にならない。adapter-node を使ってビルドしたソースコードを調べてみると svelte.config.js に設定した値がリテラルで埋め込まれていることがわかった。node.js サーバーの起動時に環境変数などを参照して動的に設定することはできない。次の issue が登録されている。

ビルド時にパスを固定にしないと、他のスクリプトソースやアセットの管理で煩雑になるところがあるのだろうと推測する。本当は環境変数で起動時に動的に変更できると、お客さんの環境にあわせて base path の値を変えたりもできるが、現状ではこちらが決めた値を固定で使ってもらうしかないことがわかった。

健康診断前は安静に

今日の運動は腕立て,スクワットをした。統計を 運動の記録 にまとめる。明日は健康診断があるのでよい数値を得るために今日は休養して安静にしようと思う。

オフィス移転祝

お手伝い先の会社が6月1日にオフィス移転をする。感覚的に引っ越ししたら胡蝶蘭を玄関に並べてあるイメージがあって、ちょうどよい機会なのでうちも送ってみることにした。

この記事によると、次の2つのパターンのときは移転祝いを送らない方がよいらしい。

  • 事業縮小による移転
  • 移転祝いを辞退している

お手伝い先はどちらにも該当しないから送って大丈夫だと思う。初めて胡蝶蘭を購入して送付する手続きをする。適当にオンラインで検索して PREMIER GARDEN というサイトから手配をした。取引関係のある法人だと2-5万円ぐらいが相場になるらしい。適当にみて27,000円の白の胡蝶蘭 (3本立て) にした。立て札も法人なら縦書きがよいらしい。胡蝶蘭を送る慣習は花言葉が「幸せが飛んでくる」となっていて、さらに胡蝶蘭には「根付く」という意味があって「幸せが根付く」という意図も込められているらしい。そんなことも知らんかった。機会があってよい学びになった。

歯科検診

17時から歯科検診へ行ってきた。今日はベテランっぽいスタッフの方が担当でとても効率よく巧く歯のお掃除をやってくれた気がする。時間も早かったし、口をあけた状態で作業される不快さもいつもより少なかった気がする。機械を使った作業でも、人間の手際のよさで大きく違うものやなと思った。

svelte の情報収集

19時から Svelte Japan Online Meetup #3 にオンライン参加した。もう私はほとんどフロントエンドの開発に携わっていないけれど、アーキテクチャや大きな開発の方針などをメンバーに指導していくためには svelte を取り巻くエコシステムの流れを把握しておかないといけない。こういったコミュニティのミートアップはそういった情報収集に役に立つ。前回から都合がつけば参加するようにしている。

svelte/kit を使っている会社の情報をまとめているという話しを聞いたので骨髄反射で pr を投げておいた。

svelte 5 はいま rc になっているそうでもう少しでリリースされそう。うちらは次の開発フェーズで移行することになると思うけれど、大きく機能や構文が変わっているようにみえるのでまたこのタイミングで私も再勉強するのがよさそうに思えた。

仕事して打ち合わせしてレンタカーの手配

0時に寝て何度か起きて6時半に起きた。ようやく生活のリズムが戻ってきた。

今日の筋トレは腹筋:15x1,腕立て:10x1,スクワット15x1をした。

sveltekit のエラー制御

svelte のエラーハンドラーの仕組みを調べた。

error() ヘルパーの内部で例外を throw して +error.svelte ファイルがエラーハンドラーでその例外を捕捉してエラーの表示を制御する。とくに目新しくない、普通のフレームワークなら用意してあるであろう例外ハンドラーのようにみえる。公式ドキュメントを読みなさいと常々メンバーに言っているが、なかなか読んでくれなくて、例外ハンドラーを知らずに自前のエラー制御を実装してしまう。私からツッコミが入って作り直しになる。公式ドキュメントを一通り読んだ方が開発が速いと何度も指摘しているのだが。

静的サイトジェネレーターの勉強会の打ち合わせ

fin-py で2月に静的サイトジェネレーターのハンズオンをやるそうで hugo なら私が使っているので紹介ぐらいできますよと言ったらそのままハンズオンの講師をやることになった。今日はそのための打ち合わせを行うことになった。だいたい次の内容になった。私以外にも4人ほど講師がいて、他の静的サイトジェネレーターのハンズオンも行う。

  • ハンズオンは1人30分を持ち時間とする
    • 質問も込みで30分
    • 時間に余裕があるので少しぐらいなら超えてもよい
    • デプロイ先やホスティングについての話しは個別にやらない
      • 静的サイトジェネレーターとは別のセッションで話す
    • ローカルでビルドするまでをハンズオンで話す
  • このハンズオンの対象とする参加者の要項を書く
    • ターゲットの参加者層を決めないと、どのレベルで解説してよいかわからない
    • git/github は使えるという前提
    • ターミナルでコマンドライン操作もできるという前提
  • 1月20日までにハンズオンのドキュメントを書いて connpass の要項を完成させる

hugo をインストールして、サイト環境を構築して、記事の生成/ビルドをする。あとはメタデータ付きマークダウンやテーマの設定ぐらいを説明するかなぁ。

開発合宿の準備

ちゃくちゃくと準備を進めている。今回は神戸から4人、関東から3人の合計7人が参加する。うちの会社の社用車で行く予定だったが5人しか乗れない。みんなで移動するのに車が2台になるのも面倒なのでレンタカーでミニバンを借りることにした。スタッドレスタイヤのオプションを付けると2泊3日で11,880円になる。これはスタッドレスタイヤのレンタルとほぼ同じぐらいの料金にみえる。これによって社用車のスタッドレスタイヤ換装の難しい課題からも解放される。キャンペーン割引があって保険も追加して2泊3日で合計61,215円となった。ミニバンなら7-8名は乗れるし、荷物も余裕をもって積み込みできる。このアイディアはいいなと思って、きのいえの定員もそのぐらいの人数がちょうどよさそうに思う。今回の開発合宿では人数の上限はどうかという点にも注目して取り組みたい。

vhs コマンドの使い方

23時過ぎに寝始めて何度か起きて7時半に起きた。

今日の筋トレは腹筋:10x1,腕立て:10x1,スクワット15x1をした。

sveltekit で context のデータを扱う

ui 側でページに依存しない形で設定情報などを扱いたいとする。svelte の store と context api を組み合わせて sveltekit として context を管理するサンプルコードが紹介されている。

これだけですぐ動くのだけど、このときに LayoutData はサーバー側で作るとバックエンドの仕組みを隠蔽できて嬉しい。そういったときは src/routes/+layout.server.ts にバックエンドの api 呼び出しを隠蔽することで意図した振る舞いになる。

import type { LayoutServerLoad } from "./$types";

export const load: LayoutServerLoad = async () => {
  const r = await fetch(`localhost:18080/myapi`);
  return r.json();
};

アニメ gif をスクリプトから作る

お気に入りのコマンドラインツールを淡々と紹介する をみていて vhs という cli でアニメ gif を作ってくれることを知った。試しにやってみた。ターミナルを録画するようなやり方と比べて、録画時にタイプミスしてしまうようなミスを防げる。次のようなスクリプトファイルを新規作成する。

$ vhs new bf.tape 
Output bf.gif

Require echo

Set Shell "bash"
Set FontSize 14
Set Width 800
Set Height 380

Type "genact -m bruteforce" Sleep 500ms  Enter

Sleep 10s

あとはこの設定でアニメ gif を作る。

$ vhs bf.tape 

これで 4.8 MiB なのでサイズはまぁまぁ大きい。サイズやカラーの調整をすればもう1桁は縮小できるかもしれない。

$ ls -lh img/2024/0110_bf.gif 
-rw-rw-r-- 1 4.8M  1月 10 19:48 img/2024/0110_bf.gif

税務相談のストレス

23時に寝て2時に起きて6時に起きた。晩ご飯食べてから作業するつもりが、疲れて寝てしまった。今日は権限管理のバグ修正したり、昨日の mongodb の調査を継続していた。

テックブログ公開

先日 テックブログレビュー を終えていた記事を公開した。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

1ヶ月に1-2件ほど折りにふれて税務相談をする機会があったりする。税理士さんとは chatwork でやり取りしている。これがストレスになってきたのではらさんに相談にのってもらった。はらさん曰く、税理士さんの普通と it 業界のうちらとは業務の取り組み方への姿勢がまったく異なるため、最初の1年はストレスや不満がたまるのはあるという。士業という資格によって独占的に保護された業務のせいか、顧客に寄り添った対応をしてくれるわけではなく、質問の背景や意図を汲んでくれなくて質問に回答を返して終わりといった、チャットなのにメールのような一問一答のようなやり取りになっている。さらに回答が意図した内容ではなくて、追加で質問や背景の説明をしても、すぐにレスポンスが返ってくることはなく、数時間たってから回答が1つ届き、それも期待したものじゃないとさらに質問して、さらに数時間といったやり取りで5-6往復するのに数日かかるのがざらにある。はらさんがいうには税理士さんの回答を得るのに1週間ぐらいかかったり、問い合わせを数日放置されるのも普通とのことらしい。

先方も複数の顧客を相手にサポートしていて、やり取りに時間がかかることそのものは理解できるが、チャットのやり取りがコンテキストを理解しているようにみえなくてコミュニケーションが成立していない。例えば、当社への税理士報酬の支払いの対応について問い合わせたら次のような回答が戻ってくるだけ。

報酬の額と消費税等の額が明確に区分されている場合には、その報酬の額のみを源泉徴収の対象とします。

こんなことはググればすぐに分かるし、私も顧問報酬は原則として源泉徴収することを知っている。その上で税理士さん事務所の、当社への顧問報酬の明細について尋ねているのにこういった回答が返ってくるだけ。

インボイス対応もあるため、請求書に明細を書いて pdf で送ってくださいと依頼して2日間返信なく放置されている。税理士さん事務所の顧問報酬の明細や請求書について尋ねても即日に返信がこないような状況になる。はらさんが言うには税理士さんの対応とはそんなもんらしい。チャットでやり取りしている意味がないし、こんなググればわかるレベルのやり取りしかできないなら解約も検討している。もう1つ懸念に思っているのは本人がチャットで回答していないのではないか?と考えている。チャットなのに1問1答でしか返信がこないし、コンテキストが伝わっていないと感じることも多々ある。とてもベテランの税理士さんが答えているとは思えないコミュニケーションの齟齬がある。

ちょっと調べてみると、税理士は日本税理士会連合会に登録する必要があり、税理士試験に合格しても登録していない場合は税理士としての独占業務を行うことができないらしい。また税理士事務所で働いている人の中には無資格職員もいて税務補助をしている可能性もあるという。必ずしも税理士資格がなければダメだというわけでもない。無資格職員でも経験を積んで税務に詳しい人もいると思う。一方でチャットでベテランの税理士のふりをして職員が回答しているのであれば、それはそれで信頼関係や偽証などの問題がある。そこら辺も聞いてみようと思う。次の記事では無資格職員が税務相談をしている事務所もあると書いてある。

全員採用のためのテックブログ

2時に寝て6時に起きて9時前に起きた。寝るのがどんどん遅くなってきて生活のリズムが乱れてきた。

sveltekit に関するテックブログ執筆

先日の続き の続き。

調査は一区切りついたのでテックブログを執筆することにした。今日はほぼ丸一日記事を書いていた。本当はマネージャーの私が1-2週間も技術調査して、テックブログを一生懸命書くみたいなことをやるよりも、他に大事なプロジェクトの遊撃やマネジメントに時間を割くべきではある。一方でメンバーに課題に取り組むにあたり、設計をどうするのか?設計をするためには調査が必要であること、調査した内容をアウトプットする重要性などの模範を示したいという意図で書いた。そして、メンバーにも開発の隙間にテックブログを書くことを業務として指示しようと考えている。

なんのためにテックブログを書くか?という目的は、業務においては明確で採用のために書く。プログラマーが採用において協力できることは限られる。その中でもテックブログというのは費用対効果が高く、会社のブランディングにもつながり、よい開発文化を醸成することにもつながる。プログラマーの採用がとても難しくなった昨今「全員採用」というキーワードもよく聞くようになった。一見プログラマーは採用において無関係だし、実際にそういった業務をやらなくても咎められることはない。しかし、自分のできることで採用に協力したいと考えたとき、できることの1つにテックブログを書くというのは悪くない選択肢だと私は考えている。少なくともテックブログを書けない (書かない) 人たちにとやかく言われたくない。

svelte コンポーネントの実装は簡単

1時に寝て何度か起きて7時に起きた。日曜日の夜に業務スーパーへ行ったら生鮮系は売り切れているのが多かった。日持ちするようなものを購入した。呪術廻戦ゲーム の初心者ミッションをクリアしたのでゲームの時間を減らしていく。

kit/vite アプリケーションのデバッグ

先日の続き の続き。

ある kit アプリケーションの svelte コンポーネントから外部の kit アプリのコンポーネントやモジュールを埋め込むことができるかどうかを調査した。ドキュメントの Loading data をみながらコンポーネントを書いてみる。フロントエンドの開発はすべてメンバーに委譲しているので私はほとんど開発していない。ドキュメントみないとまったくどう実装していよいかわからない。

svelte コンポーネントをレンダリングするときにサーバー側で動かすのは +page.server.ts に、クライアント側で動かすのは +page.ts に実装する。今回の場合、外部の node.js プロセスに起動したサーバーに対してリクエストして index.html に相当するものを取得するのでサーバー側で取得したレスポンスから html を取り出して、それをコンポーネント側でレンダリングする。+page.server.ts は次のように実装する。

import type { PageServerLoad } from './$types';
import { apps } from '$lib/index';

export const load: PageServerLoad = async ({ params }) => {
	const res = await fetch(apps['kit-demo1'].entrypoint);
	const html = await res.text();
	return { html };
};

この html をクライアント側の +page.svelte から参照してレンダリングする。

<script lang="ts">
	import type { PageData } from './$types';
	export let data: PageData;
</script>

<div>{@html data.html}</div>

これで一応は意図した kit アプリケーションを埋め込むことはできるが、実際にはスクリプトなどはなにかが競合して動かないようだ。これは node.js から取得するスクリプトやスタイルなどが複数の kit アプリケーションで競合してしまうからではないかと推測する。

これが ssg ならば adapter-static を使ってビルドして、その成果物を static ディレクトリ配下に置くだけでそのまま動く。これは特別ななにかではなく、kit アプリケーションとして意図した振る舞いにはなる。これが出来て嬉しいことはあまり思いつかないが、想像した通りに動くかどうかの検証のために確認した。

次のリポジトリに調査した内容のサンプルコードを作った。ここまでの調査内容でまたテックブログを書いてみようと思う。

複数の kit アプリケーションを共存させる仕組みの考察

1時に寝て3時に起きて5時に起きて7時半に起きた。なんとなく布団に入らずにベッドの上でそのまま寝てた。それでもあまり寒くはなかった。

kit/vite アプリケーションのデバッグ

先日の続き の続き。

kit アプリケーションを kit アプリケーションに埋め込むといったことができないかどうかの調査をしている。いろいろ調べている中で kit の discussions でもそういった議論はいくつか行われている。マイクロフロントエンドというキーワードも出てくる。

これらの議論をみていても kit の ssr はそれ自体が1つのアプリケーションとして動かすことを前提にビルドされているため、kit アプリケーション内に別の kit アプリケーションを埋め込んだり、一部のコンポーネントを外部のアプリケーションと組み合わせて動かすことはなかなか難しいようにみえる。マイクロフロントエンドのような思想で設計されていない。しかし、既存のアプリケーションを動かしつつ、少しずつ kit アプリケーションへ移行するといった運用をしたいという世の中のニーズも根強いことが伺える。

ここで svelte.config.js でエントリーポイントを置き換えるぐらいはできる。デフォルトは / がエントリーポイントになるのを /myapp に置き換えるには次のように設定する。relative は es モジュールのインポートを相対パスで行うか、絶対パスにするかの設定も変更できる。これもデプロイ先のインフラの都合にあわせて調整できるようになっている。この設定を切り替えられるのだからエンドポイントをハックすること自体はそう難しくないのかもしれない。

kit: {
  paths: {
    relative: false,
    base: '/myapp'
  },
}

さらに調査していて、adapter-node を使ってビルドするとデフォルトでは polka というアプリケーションサーバーが起動するコードが生成される。

function polka (opts) {
	return new Polka(opts);
}

const path = env('SOCKET_PATH', false);
const host = env('HOST', '0.0.0.0');
const port = env('PORT', !path && '3000');

const server = polka().use(handler);

server.listen({ path, host, port }, () => {
	console.log(`Listening on ${path ? path : host + ':' + port}`);
});

ここで任意のアプリケーションサーバーを使いたいという issue があって、それに対する回答から adapter-node のドキュメントにカスタムサーバーについて書かれていることに気付く。

アダプタは、ビルドディレクトリにindex.jsとhandler.jsの2つのファイルを作成します。index.js を実行すると (デフォルトのビルドディレクトリを使用している場合は node ビルドなど)、設定されたポートでサーバが起動します。

あるいは、Express、Connect、Polka(あるいは組み込みのhttp.createServer)に適したハンドラをエクスポートするhandler.jsファイルをインポートして、独自のサーバをセットアップすることもできます。

handler.js さえインポートすればそのまま動くことはデバッグしていて知ってはいたのだけど、この自前のアプリケーションサーバーを hooks を使って起動すれば任意のサーバーに置き換えできると issue の中で回答されていた。kit アプリケーションは1つのサーバーが1つのシステムとして動かすことを前提に設計されているが、サーバーを複数起動することでそれらを共存できるのではないか?と考えた。検証のために node.js から子プロセスを生成するには次のようなコードで起動する。些事だけど adapter-node の生成したコードが shell を介しないとポート番号を設定できなかったので shell: true もセットしている。

import { spawn } from 'child_process';

export function start_server() {
  console.log('called start_server');
  const opts = {
    shell: true,
    env: {
      ...process.env,
      PORT: '3005',
        ORIGIN: 'http://localhost:5174',
      NODE_ENV: 'production'
    }
  };
  const node = spawn('node', ['apps/myapp/build/index.js'], opts);
  node.stdout.on('data', (data) => {
    console.log(data.toString());
  });

  node.stderr.on('data', (data) => {
    console.error(data.toString());
  });

  node.on('exit', (code) => {
    console.log(`Child exited with code ${code}`);
  });
}

この node.js の子プロセスを起動する処理を hooks で呼び出すことである kit アプリケーションを起動したときに、別の kit アプリケーションを提供するアプリケーションサーバーの node.js プロセスも起動できる。そしてパスを解決できるようにするため、さらに es モジュールのインポートパスにあわせたプロキシを実装する。

import { start_server } from '$lib/index';

start_server();

import type { Handle } from '@sveltejs/kit';

export const handle: Handle = async ({ event, resolve }) => {
  if (event.url.pathname.startsWith('/myapp')) {
    if (event.request.method == 'GET') {
      return fetch('http://localhost:3005' + event.url.pathname);
    } else if (event.request.method == 'POST') {
      const data = await event.request.formData();
      const endpoint = 'http://localhost:3005' + event.url.pathname + event.url.search;
      return fetch(endpoint, { method: 'POST', body: data });
    }
  }
  const response = await resolve(event);
  return response;
};

これは kit のデモアプリが動くことを確認するためだけに実装したプロキシで GET/POST のリクエストを localhost:3005 に起動した node.js のプロセスへプロキシしている。これで2つの kit アプリケーションが1つのサーバーで共存しているかのように振る舞うことは確認できた。この延長上に私のやりたいことが実現できるかどうかをさらに調査する必要がある。

sveltekit/vite アプリケーションの調査を再開

1時に寝て起きたか起きてないか覚えてない感じで6時に起きた。起きてちょっとゲームして気付いたら7時だった。

kit/vite アプリケーションのデバッグ

先週公開したテックブログ の続き。

vite アプリケーションのバックエンドインテグレーション の詳細を調査している。丸1日デバッグしていていくつか振る舞いがわかってきて、designer アプリケーションを作りたいという要件に対して、こうすればできるんじゃないかという仮説も立てられるようになった。いまやりたい要件は kit の ssr アプリケーションを埋め込みたい。これは要件に満たないが、kit の ssg アプリケーションならば static ディレクトリに置くだけで参照できるし、インポートパスさえ書き換えてやれば別の kit アプリに埋め込むこともできるのを確認した。意図した通りの振る舞い。

vite アプリケーションはビルドオプションで manifest.json を出力し、エントリーポイントやどのファイルがどのファイルをインポートしているかといった情報を管理している。sveltekit はこれらの manifest.json から rollup でバンドルするために manifest.js を生成している。厳密には、sveltekit では production ビルド向けのチューニングをしたビルドツールを adapter と呼び、vite のビルドをフックする場所に1つになっている。node.js サーバー向けに production ビルドするときは adapter-node を使う。この実装を読んでみると、vite がビルドした成果物に対して、再度 rollup でバンドルして成果物を作り直すといったことをしている。そして、vite の成果物 (manifest.json も含む) を抽象化したものが Builder となる。adapter は Builder のインスタンスを使ってビルドの成果物を制御できる。先の manifest.js もこのときに生成していて、rollup でバンドルするためのパラメーターの1つとして使っているようにみえる。しかし、rollup のドキュメントをみても直接的に manifest.js の説明はなく、rollup の拡張の仕組みで manifest.js を作っているというよりは、sveltekit の要件によるもののようにもみえる。ここの背景はまだよくわからない。

私はフロントエンドのことが全然わからないのでライブラリのソースコードを読みながら、ドキュメントとあわせて調べて、1つずつ理解を深めていくというアプローチで進めている。こういった調査のやり方もメンバーへ伝えていければと考えている。

小規模企業共済オンライン手続きポータル

2021年度から小規模企業共済 に加入している。今年から掛け金を7万円/月に変更した。年間で84万円の所得控除となる。ちょうど2023年9月1日からポータルサイトが作成されたらしい。いずれマイナポータルと紐付くのかもしれない。

利用登録しようと思って、メールアドレスを登録しようとしたら会社のメールアドレスはなぜかバリデーションエラーになって gmail のアドレスなら登録できた。その後も氏名の半角カナ入力を強制されたりしながら、マイナンバーカードを読み取って認証チェックして利用登録の申請はできた。しかし、自動で本登録されるわけではなく、おそらく申請内容が先方に届いてなんらかの運用があって本登録されるみたい。オンラインポータルのホームでも半角カナを使っていたり、<title> タグには「マイナ手続きポータル」とあったり、申請しただけでいくつも不備がわかるようなひどいサイトになっている。2023年にまともな開発者が作ったサイトとは思えない。デジタル庁に作り直してもらった方がよいと思う。

家族信託の打ち合わせ

1時に寝て4時に起きてもう1度どこかで起きて7時半に起きた。

テックブログ公開

テックブログレビュー を終えて公開した。この機会に 個々の記事に目次 も追加した。はらさんレビューから修正をして2時間後に公開しますよと宣言して勝手に公開した。

家族信託の打ち合わせ

15時にお仕事を早退して、親と一緒に明石市にある弁護士さんの事務所へ訪問した。三ノ宮から車で向かって、ナビゲーションに従っていたら京橋から高速道路に入って若宮でおろされて、なんでこんな早く高速道路おりるんやろ?と不思議に思ったけど、須磨からの海岸線はそれほど渋滞せず信号も多くないから下道で行ってもそんなに時間はかからないという判断だったようにみえる。だいたい40-50分ほどで明石市の中心地に着いた。3分ほど遅刻して打ち合わせが始まった。

遺産を相続するとさまざまなリスクがある。大きなお金をもつというだけで詐欺のターゲットにされる。家族信託 (民事信託) という制度を使って、そのとき必要なお金のみを受け取るように運用する。構成要素は次の通り。

  • 委託者: 母
  • 受託者: 私と姉
  • 信託財産: 預金

受託者は最低2人必要で、うちは姉もいるのでよいのではないかと弁護士さんが話されていた。たしかに1人っ子なら誰かにお願いしないといけない。大雑把に言えば、母の貯金を子どもに管理してもらうような制度になる。但し、最初の契約書に記載された内容の範囲内でしか、受託者はお金を引き出せないのでその契約書をしっかり作ることが重要になる。契約書に記載していれば、資産運用もできるらしい。契約書の叩き台として、どういった内容を書いておくかを相談した。弁護士さん曰く、契約書に書いておかないとその用途に使えなくなるため、1%でも可能性があれば、書くだけ書いておいた方がよいとのこと。書いておいて、実際に使わないというのはなんの問題もない。

3人でブレストするような感じで項目を洗い出した。

  • 生活費
    • 冠婚葬祭で払うお金
      • 10万円以内なら生活費として引き出してもよい
      • 例えば30万円いるとして、建替え可能なら10万円/月を3ヶ月かけて引き出すでもよい
    • (お金に困った親戚がいたと仮定して) 親戚への資金援助
      • 生活費の範囲内でやればよいはず
  • 看護、療養といった通院も含めた医療費
  • 老人ホームの入居費用
  • 納税 (一時所得)
    • 太陽光発電で得た収益のうち、所得税をこの口座から引き出して支払うといったこともできる
  • 家の改築、修繕、取り壊しの費用
  • 農業のための費用
    • 農機具の購入や修理など
    • トラクターが一番高い、100万円〜1,000万円ぐらいとピンからキリまである
  • 土地 (田んぼ、宅地) の購入
  • 太陽光発電設備の撤去費用
  • 自家用車の購入費用
  • 生命保険の支払い
    • 死亡保険金は500万円 x 法定相続人数まで非課税なので相続税の節税になるらしい
      • 例) 母の死亡時に姉と私が500万円受け取るような生命保険に入る
    • 相続税の基礎控除が3,000万円 + 600万円 * 法定相続人数
      • 例) うちは私と姉で 3000 + 600 * 2 = 4,200万円が基礎控除となる
        • この金額を超える遺産があれば相続税の課税対象となる
        • 生命保険へ付け替えることで 4200 + 500 * 2 = 5,200万円まで非課税にできる?
  • 資産運用
    • 投資信託
      • 積み立て系の投資信託がもっとも望ましいのではないか
        • リスクヘッジとして大きなお金を1度に動かすのはなるべく避けたい
        • NISA 口座を開設できるかどうかは調べないとわからない
      • 信託口座とは別に証券口座も開設しないといけない
        • 受託者が預金口座からお金を引き出して証券口座へ振り込むような運用になる?
      • 具体的にどういった運用にするかは信託銀行と応相談になるかもしれない
        • なんらかの制約が課されるのではないかと推測される
    • 株式投資
      • 可能ではあるが、条件を指定しないといけないため、中長期での実運用は難しいのではないか

私が信託口座からお金を引き出すときに、一定金額以下の生活費 (例えば10万円) ならノーチェックだが、100万円とか大きなお金を引き出すときには銀行員からチェックがかかり、正当な使途なのかどうかを確認されるという。場合によっては見積もり書の提出なども必要かもしれないとのこと。それはとくに問題ない。契約書の作り直し自体は委託者が元気であればできる。しかし、手数料や手間暇もかかるため、実運用としては最初に作った契約書を変更するといったことはそうそう行われない。最初が大事。弁護士さんが契約書を作成するのに2-3週間かかる。その後に三井住友銀行さんで赤ペン先生のチェックが入る。契約内容の修正などのやり取りをしてその後手続きに進む。

思考実験として、詐欺にあって借金してしまった、または連帯保証人となって借金してしまった。その場合はどうなるか?というのも考えてみた。信託銀行に確認してみるとのことだったが、弁護士さんが言うには、家族信託の目的は財産を守ることにあるため、本来の使途ではないものへ支払いは抵抗があるかもしれないとのこと。その状況によって銀行員の判断次第かもしれないとのこと。

受託者は年に1回報告書 (帳簿) を作り、どのように運用したかを委託者へ報告する義務がある。これは家族間だけの話ではある。この手の情報処理 (データ処理) は私が得意とするのでそんなのすぐやりますと回答できた。弁護士さんによると、こういう事務作業を嫌がる受託者もいるという。スプレッドシートでちゃちゃっと作ればよいはず。

契約書を作成したら、それをもって委託者、受託者、弁護士の3人で 神戸公証役場 へ一緒に行く。その公正証書をもって三井住友信託銀行へ行って、母が口座を開設して、そこに弁護士さんが遺産を振り込むといった段取りになる。将来、委託者の健康を害して成年後見人がつく状況になったとしても家族信託の口座はそのまま受託者が管理できる。成年後見人に信託口座が移管されるようなことはない。

最後に契約書の条項をチェックしていて次の内容を教えてもらった。

弁護士業務の適正の確保

甲は、本件事件等の処理の依頼目的が犯罪収益移転に関わるものではないことを、表明し保証する。

「半社チェックのようなもの?」と聞いたらちょっと違っていて、弁護士は大きなお金を動かしても監査を受けないという特権 (信頼) があって、その特権はマネーロンダリングできてしまうという諸刃の剣でもあるらしい。今回のお金は遺産なので半社会的なものに該当しないが、契約書では弁護士が扱う業務がマネーロンダリングではないことをチェックする必要があるみたい。

帰りに 明石焼き ゴ というお店で明石焼きを買った。駐車場の近くにあったお店に立ち寄ってテイクアウトしたのだけど、とてもおいしかった。それで 食べログ の評価もみたら 3.49 とかなり高い。たまたま買ったところがよいお店だった。18時半頃に店内もほぼ満席だったと思う。また明石へ行く機会があれば寄ってみようと思う。

フロントエンドのビルドツールと vite

22時に寝て0時に起きて2時間ほどネットで遊んで寝て5時に起きて7時に起きた。16時半にお仕事を終えて、雨降りの中、芦屋まで出掛けて能をみてきた。

svelte/kit と vite

水曜日から vite の機能や振る舞いについて調べている。厳密には svelte/kit (svelte と svelte kit の両方を指している) はどうやって .svelte ファイルや他のソースコードをコンパイルしているのかを調べ始めた。kit のコードを調べても svelte のコンパイルをしているようにはみえない。vite.config.ts には次のように kit が提供しているプラグインを使っているようにみえる。

import { sveltekit } from '@sveltejs/kit/vite';

...

export default defineConfig({
	plugins: [sveltekit()]
});

このコードを追っていくと、次のように vite-plugin-svelte からプラグインを設定するコードがある。

import { svelte } from '@sveltejs/vite-plugin-svelte';
...
export async function sveltekit() {
    ...
    return [...svelte(vite_plugin_svelte_options), ...kit({ svelte_config })];
}

vite-plugin-svelte のコードを調べていくと、load や transform といったフックポイント に svelte のコンパイラを呼び出すコードがみえてくるようになる。

compileData = await compileSvelte(svelteRequest, code, options);

svelte のコンパイルは vite の仕組みを使って vite-plugin-svelte に実装されている。それなら vite はどうやってフレームワークのコンパイルを実現しているのだろうか?という疑問に行き着く。その背景を調べたり、ドキュメントを読んだり、実際にサンプルコードを動かしながら検証したりをこの3日間やっていた。自分なりの仮説はできたけれど、本当にその仮説のような振る舞いをしているかの実証がまだできていない。週末に余裕があれば、それをやっていきたい。

2階席からの能鑑賞

行きは三ノ宮から JR で8分、帰りは阪神電車で12分の芦屋駅から徒歩10分ほどで芦屋ルナホールへ着く。第二十二回芦屋能・狂言鑑賞の会 へ行ってきた。前月に 蝉丸の予習 をして準備万端で臨んだ。芦屋ルナホールに着いたら17時過ぎで受付をしてエレベーターで4Fまで。ホールの2階席が物理的には4Fにあった。芦屋ルナホールの2階席は見晴らしがよくて、能を斜め上から俯瞰してみるという、これはこれで独特の視点をもってみれておもしろい。ホールは能舞台ではないので、普通の舞台に高座の床を敷いて周りに松をいけて、簡易の能舞台をこしらえていた。

ちょうど一調の「花月」が終わったところで、2つめの演目の狂言「濯ぎ川」をみて、芦屋市長挨拶して、能の蝉丸という順番だった。芦屋市長と言えば 歴代最年少26歳で市長になった 方で挨拶を聞いていても生徒会長が挨拶をしているような雰囲気で若い。こういった若くて優秀な方が若い感性で活躍してほしいと思う。

蝉丸が始まった。シテは逆髪で、ツレが蝉丸になるという。どちらも能面をしていた。ワキは能面をつけないことは知っていたが、ツレは能面をつけていいんだということを知った。

ストーリーを知っていると謡や詞章が聞き取れるかと期待したが、まだまだそんなことはなくて、紙に書いたものがないと付いていけない。「能のことばを読んでみる会」でもらった詞章をもっていけばよかった。あとイヤホンがあれば朝原さんのスマホ解説を聞けるのだが、それを聞きたいと思いつつ、いつもイヤホンを忘れてしまって聞けない。次回こそイヤホンを忘れないようにしたい。

それでも所々、記憶に残っている内容と演者が話しているところは理解できて、普段よりも能の物語の展開を理解できたと思う。一方で地謡 (横に座っていて集団で謡う人たち) が能の所々で謡が始まるとき、シテやワキがずっと待っていて時が止まっているかのような感覚になる。いままでもそういう展開だったはずだけど、今回はストーリーが頭も中に入っているので、逆髪、蝉丸、清貫のやり取りが止まってしまって、続きが待ち遠しいように思えた。テレビをみていて CM が入るような感覚。

囃子は笛・大鼓・小鼓の3人体制だった。これも物語の要所で盛り上がりを演出している。囃子の盛り上がりを聞いていると、ここが見せ場の場面なのだと自然に観客を引き込むことができる。最後の逆髪がじゃあまたねって、あっさり帰るところに蝉丸がもう帰っちゃうの?と嘆くところとか、囃子が盛り上げるのかと思ったらそうでもなかった。途中のどこかの場面が一番盛り上がりを演出していた。

予習してこんな物語の展開になるのかな?と予想していたものと、実際の能をみているとイメージ通りではなかった。それは地謡の謡いの合間が私の頭の中には入っていなかったから。次に「能のことばを読んでみる会」へ行くと地謡のところがこんな雰囲気なのかとイメージできるようになる。いずれにしても、詞章と能の関係における解像度は少し上がったように思う。まだまだ能をみていて幻視をみるというのはほど遠い。こうやって少しずつ解像度を上げていければと思う。