0時に寝て3時に起きてちょっとネットみたりしてまた寝て7時に起きた。

今日の筋トレは腹筋:10x2,スクワット20x1をした。

ストレッチ

筋トレの疲労がたまっているのかもしれないが、今日も太ももの後ろの筋がかなり張っていた。胸筋もやや張りがあったように感じた。トレーナーさんによると、筋トレした後に使ったところはストレッチして伸ばした方がよいという。今日の開脚幅は開始前153cmで、ストレッチ後156cmだった。先週とほぼ同じ。

筋トレを継続できているのでトレーナーさんにいろいろ聞いてみた。

• 筋トレメニューに慣れてきたら強度をあげる？回数を増やす？
  • 回数を増やした方がよい
  • 負荷をかけてしんどくなるとフォームが崩れて適切なトレーニングではなくなる懸念がある
• 種別をもう1つ増やすなら何がよいか？
  • 背筋がいいんじゃないか
• 筋トレを毎日やるのはどうか？
  • 大きな筋肉を使うトレーニングは2-3日休みを入れながらやった方がよい
  • 小さな筋肉なら毎日でも構わない
  • 私がやっている筋トレは10分でできるようなレベルなので毎日でよいだろう

電子帳簿保存法対応の事務処理規定と運用ガイドラインの策定

税理士さんに 電子帳簿保存法対応の事務処理規定の叩き台 をレビューしていただいた内容を規定に反映した。念のため、再レビューしてもらうが、これで完了とする予定。規定から実際の運用のためにガイドラインを作る。運用ガイドラインは notion にまとめる。

あまり notion を使う気になれないのは、課題管理システムをメインに使っているから wiki もそこにセットで付いていてほしいという願望がある。うちは jira cloud を使っているので本当は atlassian の wiki プロダクトを使いたいところだが confluence が使いにくいから使っていない。atlassian は confluence とは別にもっと軽量でシンプルな wiki プロダクトを別途提供すればよいのでないかとすら思う。一方で esa や notion のような、wiki 単体のサービスを活用するのは課題管理システムとの連携において不便なように思えた。だから notion は最近プロジェクト管理の方に手を広げているのかもしれない。 github や gitlab のように、課題管理システムと wiki はとても相性がよいのでツールセットで提供するのがよいと思う。今後のプロダクト構想の中で wiki を考えていなかったけれど、アプリケーション間連携という視点から考察してもよいかもしれない。

sns などで電子帳簿保存法対応がすごく大変といったメッセージをたまにみかける。この法律は電子取り引き (請求書や領収書を pdf ベースでやり取りするサービスなど) に対応するもので紙の請求書や領収書でやり取りしている事業者には影響はない。しかし、昨今取り引きが電子化されていく流れでもあるため、電子取り引きはまったくないという事業者もあまり存在しないのではないかと思う。そして、これまではそういった事業者が取り引きの証拠となる電子データを消失してしまっても法律から言及できないという状態だった。電子取り引きはデータしかその取り引きがあったことを証明する証拠がないのにそのデータを消失して OK なわけないよね？というのが本来の電子帳簿保存法の目的になる。

おそらくパソコンやシステムでデータ管理していない事業者にとっては取引データ保存の仕組みや運用を新規構築する必要があってコスト増になって大変なのだと推測する。しかし、私のような、最初から大半の取り引きは電子取り引きであり、そのデータもすべてクラウドストレージに整理した上で保存している事業者にとってはほとんど運用に影響を与えない。もちろん現行の運用にあうようにするには事務処理規定を策定しないといけない。ここで影響があるのは訂正・削除の運用時に記録を残すという点ぐらいしか、既存の運用と変わることはない。そして、過去の電子取り引きの訂正・削除が発生したことは私の記憶にないぐらい稀にしか発生しないと推測される。

低辺 sier のひどい労働環境や多重請負契約の構造を it 業界の代表的なもののように揶揄されるのと同様、いかに世の中のできない人たちが自分たちのスキル不足や知識不足を大騒ぎしてその内容が正当であるかのように喧伝しているのかが伺える。まともにシステムを使っている会社は電子帳簿保存法で大きな影響を受けない。多少の運用手順が変わったり、システムの開発が必要になったりする程度だと思われる。これはインボイス対応もそう。うちのようなマイクロ法人でもインボイス対応は新規の取引先を登録していく作業が増えたぐらいで日々の会計処理にほとんど影響を受けていない。世の中のニュースと実際の実務運用に大きな乖離がある。そして、実際にやったこともないような人たちが「弱者いじめ」だと党派性をもって大騒ぎする。

モニター変更

これまで27インチと24インチのダブルディスプレイを使ってきた。実家 (コワーキングスペース) に27インチのモニターを持って帰ろうと思って、24インチのモニターをもう1つ買ってその入れ替えをしていた。24インチ x 2 のダブルディスプレイに変更した。27インチ x 2 は有効視野を考えると幅が広過ぎて私にはあわない。首振りが疲れる。1台でもっと大きいモニターを使うという選択肢もあるかもしれない。しかし、私はなんとなく2台のディスプレイで1つをコードを書くメイン、もう1つをブラウザで調べたものを表示させておくためのサブという使い方を気に入っている。ただの習慣かもしれない。

人間の視野は左右の眼を合わせると180度以上あります。 片眼の視野は鼻側に約60度、耳側に約100度、上方向に約60度、下方向に約70度と言われています。その中で、標識の文字を読むなど、モノのカタチや色などがキチンと認識できる範囲を中心視と言い、わずか1～2度ほど。中心視のまわりの必要なものを識別できる範囲、有効視野は左右に35度ほど。その外側である周辺視野では、カタチや色などをハッキリと認識することはできません。

中心視と周辺視野

オフィス掃除

モニターを入れ替えしたら埃っぽくなったのでついでにオフィスも掃除した。掃除機は sharp の EC-CT12-C を使っている。サイクロンだからパワーもあるし、ゴミ捨ても紙パックいらないから簡単。コンパクトで数ヶ月に1回ぐらいしか使わない私の用途にちょうどよい。普段は箱にしまってある。

箱から掃除機を取り出して、終わったら片付けるときに箱にしまい方も書いてある。他の掃除機はどうなのか知らないけど、たまにしか使わない家電で使ったらまた箱にしまうよねと気の利いたこの絵が嬉しい。掃除機を作ることに一生懸命だとこういう気遣いはできない。こういった配慮ができるのは会社の文化や組織や開発体制に「余白」があるからじゃないかと、私もマネジメントをしていて最近は思うようになってきた。この絵があるからこの掃除機を購入するわけではない。それでも、この掃除機を使っていて故障してもまた sharp の掃除機を買おうかなという気持ちにさせる。

部屋のレイアウト変更

マンションに帰って22時半から部屋のレイアウト変更を始めた。少し前に ホットクック を購入したものの、思いの外、大きくて置く場所がなくてそのための 置き台 をジモティーで購入していた。その置き台を台所の横に設置するには、本棚をどかす必要があって、それは重労働になるのでついつい先延ばししていた。こんな感じ。

設置して無線 LAN の接続や COCORO HOME に家電登録してアプリ間連携の設定をしていた。私のような Web 系の開発者からみると設定 UI やわかりにくさはひどいものだったが、家電メーカーの作るアプリはそんなものだろう。ホットクックの WiFi は 2.4GHz しかサポートしていない。うちの無線 LAN ルーターは 5GHz only で稼働させていたので 2.4GHz も有効化して接続した。私が購入したホットクック (KN-HW24G-W) は COCORO KITCHEN に非対応だった。COCORO KITCHEN は deprecated で今後は COCORO HOME になるのかな？COCORO KITCHEN で家電登録しようとしてうまくいかないとまごまごしていた。

23時に寝て4時半頃に起きてそのまま6時半までだらだらして起きた。早寝早起き。

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

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。内容が多くて1時間超えた。

• 電子帳簿保存法対応の事務処理規定の共有
  • まだ始まったばかりで税理士さんの温度感も低い
  • 事務処理規定が省令に沿っているかどうかの判断はプロセス監査で行われる
  • 電子帳簿保存法には規定されていないため、事務処理規定の妥当性の検証は行われない
• 融資を受ける構想作り
  • 日本政策金融公庫のみで検討していたが、融資実績を作りたいなら信用金庫も加えた方がよい
  • 借金のメンタリティ、担当者との折衝や審査など余裕のあるときに経験を積んでおくことはよいように思えた
• ファイナンシャルプランナーさんとのやり取り
  • 会社の経費で役員のための保険に入ろうと考えている
  • 個人の保険控除は8万円らしい
• ローカル複業化プロジェクトの考察
  • IT コミュニティに老人や子どもたちは入りにくい。農業なら老若男女誰でも入れる気がする
  • 農業や地元の特産品を切り口にコワーキング (コミュニティ) で街の人たちと田舎の人たちをつなげるのはすごいことだと思う (関係人口の創出)
  • 地元の有力者と仲良くなると、行政の口利きもしてくれて活動しやすくなる

はらさんが よりひろいフロントエンド を始めたそうでその話しも聞いていた。個人のブログサイトにするのか、複数人で記事を共有するサイトにするのかもまだ曖昧だという。Contentful + Next.js + Cloudflare Pages という構成らしい。Contentful というツールを私が知らなかったのでまた時間のあるときに調べてみようと思う。

母が一人暮らしをしていて体調もよくないことから要介護状態になるリスクがそこそこあると考えている。最悪の場合、会社を休眠させてしばらく介護をするかもしれない。はらさんが仰るには休眠はよいアイディアだという。会社員に例えると退職した日の帰り道を想像するとよいと話されていたのだけど、私は過去の記憶があまりないというのもあるが、これまで6回も退職してきたのに退職日を特別に思ったことはあまりない。退職日と他の日に大きな違いはなくて、次のお仕事の準備や調査をしていることが私は多かったと思う。それでも退職にあわせて有休を1-2ヶ月とってゆっくり過ごしていたことには変わりない。私もそういう、メリハリのある働き方が好きだ。

smtp 接続のタイムアウト

たまたまメンバーが誤った設定で smtp サーバーに接続したときにタイムアウトするまで5分ほどかかるという現象を発見した。タイムアウトの設定をせずに接続しようとするからそんなことが起きるのかな？と考えて smtp クライアントのタイムアウト設定を調べてみると net.DialTimeout を使えばよいという。

• https://github.com/golang/go/issues/16436#issuecomment-233829112

多めに見積もって30秒のタイムアウトを設定して接続するようにして再度メンバーに再現検証してもらったら直っていないという。接続そのものは出来ていたのだ。ソースを読んでみると、smtp クライアントを生成するときに 220 というレスポンスを読むことがわかる。誤った接続設定でもコネクションは確立するが、レスポンスが返ってこなくて待ち状態になっていた。

func NewClient(conn net.Conn, host string) (*Client, error) {
	text := textproto.NewConn(conn)
	_, _, err := text.ReadResponse(220)
	if err != nil {
		text.Close()
		return nil, err
	}
	c := &Client{Text: text, conn: conn, serverName: host, localName: "localhost"}
	_, c.tls = conn.(*tls.Conn)
	return c, nil
}

調べてみると Conn インターフェースにデッドラインを設定する API が提供されている。注意事項としては接続した後にデッドラインをリセットしないといけない。

デッドラインとは、I/O操作がブロックされずに失敗する絶対時間のことである。デッドラインは、ReadやWriteを呼び出した直後のI/Oだけでなく、将来の保留中の I/O すべてに適用される。デッドラインを超過した後は、未来にデッドラインを設定することで、接続をリフレッシュすることができる。

デッドラインを超えた場合、ReadやWrite、その他のI/Oメソッドの呼び出しは、os.ErrDeadlineExceeded をラップしたエラーを返します。これは、errors.Is(err, os.ErrDeadlineExceeded)を使用してテストすることができます。errorのTimeoutメソッドはtrueを返しますが、期限を超過していなくてもTimeoutメソッドがtrueを返すエラーが他にもあることに注意してください。

アイドルタイムアウトは、ReadまたはWrite呼び出しに成功した後、デッドラインを繰り返し延長することで実装できる。tの値が0であれば、I/O操作はタイムアウトしない。

https://pkg.go.dev/net#Conn

次のように SetReadDeadline() を使ってタイムアウトを5分から30秒に短縮できた。

func (s *Clinet) connectWithReadDeadline(conn net.Conn) (*smtp.Client, error) {
	if err := conn.SetReadDeadline(time.Now().Add(dialTimeout)); err != nil {
		return nil, fmt.Errorf("failed to set read deadline: %w", err)
	}
	c, err := smtp.NewClient(conn, s.config.Host)
	if err != nil {
		return nil, fmt.Errorf("failed to connect to the smtp server: %w", err)
	}
	// clear read deadline
	if err := conn.SetReadDeadline(time.Time{}); err != nil {
		return nil, fmt.Errorf("failed to reset read deadline: %w", err)
	}
	return c, nil
}

1時過ぎに寝て6時半に起きた。久しぶりによく眠れた。6時半に起きてたのに8時ぐらいまでだらだらしてた。

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

windows server 2022 試用版のインストール

Windows Server 2022 の試用版が提供されていると知ったのでローカルの VirtualBox 環境にインストールしてみた。Active Directory の検証に使うのでディレクトサービスや ldaps 接続のための証明書サービスなどを設定する。メンバーがインストールして課題管理システムにメモを残してくれてあったのでそれを見ながらインストールや設定自体はすぐにできた。1つだけうまく接続できないことがあった。

ホスト os から ldapsearch で ldaps で接続しようとすると次のようなエラーになる。

$ ldapsearch -x -H "ldaps://192.168.56.101" -W -b "CN=Users,DC=myad,DC=com" -D "CN=Administrator,CN=Users,DC=myad,DC=com"
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

ldap では接続できるので tls の検証のチェックに失敗していることは自明だったが、メンバーは接続できているようにみえたので私の環境の設定が誤っているのかどうかを調べていた。2時間ぐらいデバッグしたりしながら調べてもよくわからなくて、たまたまチーム勉強会があったので終わったときにメンバーに聞いてみた。すぐに完結した。ldapsearch は LDAPTLS_REQCERT という環境変数で tls のリクエストの振る舞いを制御できる。次のように明示的に指定すると接続できる。

$ LDAPTLS_REQCERT=never ldapsearch -x -H "ldaps://192.168.56.101" ...

この設定はいくつかの方法で設定ファイルに書いておくこともできる。メンバーが使っている環境には ldap.conf でこの設定を有効にしていたので ldaps 接続できていたというオチだった。私が openldap について明るくないのでこういった背景知識をもっていなくてはまっていただけだった。

Thus the following files and variables are read, in order:
    variable     $LDAPNOINIT, and if that is not set:
    system file  /etc/openldap/ldap.conf,
    user files   $HOME/ldaprc,  $HOME/.ldaprc,  ./ldaprc,
    system file  $LDAPCONF,
    user files   $HOME/$LDAPRC, $HOME/.$LDAPRC, ./$LDAPRC,
    variables    $LDAP<uppercase option name>.
Settings late in the list override earlier ones.

明石海峡大橋海上ウォーク

神戸ジャーナルの記事をみかけて、そういうイベントがあるのは知っていた。

• 神戸淡路鳴門自動車道 2橋ウォーク同時開催！ 明石海峡大橋海上ウォーク/大鳴門橋うずしおウォーク 令和6年3月9日(土)・10日(日)

開発合宿の翌週だし、わざわざ行くほどでもないかとスルーしていたものの、関東から知人がわざわざ歩きに来るという話しを聞いて、せっかくの機会なので私も参加することにした。土曜日の午前中に明石海峡大橋を歩いてくる。まだ申込みが始まったばかりなので希望の時間帯を選択できると思う。

3時過ぎに寝て1度起きて7時半に起きた。また体調を崩さないか心配になってくる。

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

業務での勉強のやり方の基本

隔週で水曜日はメンバーと1on1をしている。今日は年明けで最初の1on1になる。あるメンバーと勉強のやり方について話題になった。私が普段、業務で行っている勉強のやり方を紹介してみた。

1. 業務の中で未知の内容やわからないことに遭遇する
2. ツールやフレームワークを学ぶなら公式ドキュメントを一通り読む
3. チュートリアルやサンプルコードを書くためにサンプルリポジトリを作る
4. 実際にコードを書いて、動かしてみて、ドキュメントの内容を理解する
5. 自分が理解した内容をテックブログに書く
6. 対象への理解の解像度が上がってから業務に応用する

業務をしながらこれを繰り返してプロダクト開発をしている。

私からみると、経験の浅い開発者は勉強せずに、インターネットでググった内容をそのまま業務に応用しようとする。そして、理解の解像度が低いために誤った設計や実装をしてしまう。それで手戻りが発生したり、品質が悪かったりする。何度も公式ドキュメントを読んだ方がよいと提唱しているものの、これがなかなか勉強しないといけない人には通じない。私も過去にそういう時期があったので意図が理解できないというのも理解できる。だからこそ、この話しは何度でもするし、いつかそのことを理解できるときがきたら役に立つことだと考えている。

メンバーから「公式ドキュメントを読んでも書いてあることが理解できない」というコメントをもらう。そう。理解できないから自分でコードを書いて、動かしてみて、その勉強をするんだよと教える。本当にそれだけのことなんだけど、それだけのことも理解できずに他人が書いた信頼できるかどうかわからない記事のコードを使う人が多い。本質的には技術の勉強を過小評価している。経験の浅い人は1-2時間読み書きしただけでモダンなフレームワークの抽象化や振る舞いを理解できるはずがない。私でもバックエンドならたいていのことは理解できるが、経験の浅いフロントエンドは怪しい。だから、分かるまでもっともっと勉強しないといけないという認識が必要だ。1-2時間で終えようではなく、勉強も含めて2-3日かけようと思うぐらいでちょうどよい。

さらに私はメンバーに「時間がかかってもよいからちゃんと理解して開発しなさい」と、これも何度も何度もメンバーに伝えている。それによってタスクが遅れても構わないとすら言っている。他社のプロダクト開発でそこまで言うと経営者からクレームがくる可能性はあるが、おそらくお手伝い先の経営者もいっときの開発の速度よりも、地に足の着いた開発者として成長してもらう方がずっと価値があると理解してもらっていると、私は考えている。だからこそ、メンバーにそう言って、みせかけだけで開発しないように伝えている。

今日話していて、ようやく自覚できるようになってきたんじゃないかと手応えを感じた。1年かかったけれど。私自身マネージャーとして未熟でもあるし、マネジメントがよくなかったところもあるし、伝え方もよくなかったのかもしれない。それでも繰り返し繰り返し、開発において大事な価値観はメンバーに伝えていこうと気持ちを新たにした。

災害義援金の推移

先日 石川県の災害義援金に寄付した ときにサイトにその日の残高を掲載していることに気付いた。関心をもったのでその記録を付けている。チェックを忘れたときは internet archive から分かる範囲で調べた。次のような感じに推移していて、そろそろ落ち着くのかもしれない。約60億円といったところ。他の団体や期間からの寄付もあるだろうけど、被害総額は約8,000億円らしいのでまだまだ全然足らない。

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

月例のカフーツさんのオンラインイベントに参加した。前回の所感はここ 。今回のテーマは「自治体とコワーキング」だった。私は行政を好ましく思っていない。行政と関わるお仕事もいくつかやってきた中で行政側の態度がよくなかったり、担当者も上から指示されたからやってますといったやっつけだったり、若い担当者は理解があっても決済権をもってなくて上司に没にされたり、一緒に働いていて楽しいようなお仕事に巡りあわなかったからだ。そして、目的意識からの違いから行政とのお仕事やプロジェクトが失敗とまで言わなくても、うまくいかないケースをいくつも見聞きしてきた。うまくいかないのに対して、うまくいったというのはほとんど聞いたことがないからまずうまくいかない。

それはともかく、行政と一緒になってコワーキングの事業をやろうとしている人たちもいるのでそれはそれでどんなことをやっているのかを聞いていた。今回は新しい参加者がいてその人の経歴ややっているコワーキングの行動なども聞けておもしろかった。街の人たちとどうやって仲良くなるかという話しで単純接触効果がもっとも効果が大きいのではないかと話されていた。なにもしなくてもそこにいて、徐々に人がくるようになって、人と会っているうちに仲良くなるといった話し。営業さんが取引先をまわるのもその戦略。

空き家バンク は住居向けしか対象としていなくて事業用にはなっていない。事業に使える空き家を探すのが難しい。空き家のマッチングシステムはあるようでないらしい。空き家がいっぱいあるのはわかっているので空き家をコワーキングスペースに改装して、町興しの拠点に使えばいいのではないかといった話しがあった。それはそうかもしれないが、私の感覚では、田舎にスペースは山ほどあるが人がいない。コワーキング的な新しい価値観で個々が自律して課題解決するような人を田舎でみつけるのはなかなか難しいと考えている。どちらかというと、一定の人口がいる地方都市や大きめの市が落とし所なのではないかと思う。

21時頃から寝て何度か起きて7時半に起きた。昨日は頭が痛かったら早く帰って安静にしてた。安静にしたら直ったので大したことはなかったみたい。

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

テスト環境の見直し

いまどきの開発の定番としては ci/cd でコミット単位にテスト環境にデプロイする仕組みを構築している。テスト環境は1つだけになるのだけど、プロダクトの開発を1年以上やってきて機能が増えたことによって、1つのテスト環境で相容れない複数の要件や機能を混在させることで管理や運用が煩雑になってきた。気付いたタイミングがよい時期だと思うのでこの機会に1つのテスト環境を3つのテスト環境に分散させようと思う。既存データを確認するだけなら1つでもよいが、id 連携という機能の特性上、複数のシステム間でデータ連携するため、システム間での依存関係が発生する。それを整理しないといけなくなったという次第。今日のところは現状把握や移行に必要な段取りなどを設計していた。

hugo のハンズオン資料作り

昨日の続き 。23時過ぎに外に出たついでにオフィスに寄り道して書き始めたらまた熱中してしまって2時ぐらいまで書いていた。ハンズオンで説明する内容は一通り書いたつもり。せっかくの機会だから上級者向けにもう少し知っていることを書いてみようとは思う。

4時半に寝て7時半に起きた。深夜にハンズオン資料を作っていたらまた眠れなくなった。朝から頭痛くて調子が悪い。きっと生活のリズムが崩れているせい。早くお仕事を終えて帰って寝てた。

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

ldap エントリーの更新リクエストをランダムに行うツール

先週末から作っていたテストツールがようやく一通り動くようになった。ldap エントリーを生成したり、既存のエントリーに対して更新、削除、パスワード変更のリクエストをランダムに自動生成して送る。常時 id 連携の処理を動かしたときの並行処理の問題であったり、やや負荷をかけたときになにかの敷居値を超えて不具合がないかといった検証に使える。8月末に開発に着手して、年末から再開して、1月明けでようやく完成した。テストツールの開発の優先度が低いので後回し後回しにしているうちにどんどん後ろに流れていった。悪い開発の典型例。

hugo のハンズオン資料作り

昨日の続き 、、、をやろうと思っていたけど、頭痛でしんどかったので今日はお休み。イベントが公開された。

• 静的サイトジェネレーター勉強会

他のツールをみていて slate というツールは知らなかった。api ドキュメントを書くためのツールとある。

• https://github.com/slatedocs/slate
• https://slatedocs.github.io/slate/

うちはいま redocly というツールを使って openapi のフォーマット (yml) で api ドキュメントを管理している。開発は openapi を使ってなくてドキュメントのためだけに openapi を使っている。量が増えてくると yml でドキュメントを書くのも辛くなってくるので markdown で api ドキュメントを書けるならそれもよいかもしれない。

2時過ぎに帰ってなんか眠れなくて4時半に寝て8時に起きた。なんか夜型になってきて変な生活リズム。

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

hugo のハンズオン資料作り

昨日の続き 。

朝からいろいろ直していた。やり始めると凝ってくる。スタイルやシンタックスハイライトなどを修正していた。

もくもく会

新年もくもく会 に参加した。なぜか今回は参加者が多くて15人ぐらいほぼ満席だった。lt 大会の内容は新年なので今年はこんなことやりたいという抱負を発表する人が多かったように思う。一通り lt を聞いてから、午前中に引き続き、ハンズオン資料の調査をしていた。夕方眠くなって集中力がなくなっていた。軽く1次会だけ行って眠くてそのまま帰ってきた。

hugo のハンズオン資料作り (2回目)

飲み会から帰ってきて2時間ほど寝て、それからまた再開して2時半ぐらいまでやってた。サイトの構築とテーマの設定のところを書き終えた。初心者向けにハンズオン資料を書いているが、テーマの設定はなかなか難しいなと思える。拡張を作り込んでいるテーマもあるが、設定方法のドキュメントはあまりないことが多い。デモ画面とそのソースの設定ファイルをみながら空気を読むみたいなところで初期設定をしていかないといけない。

晩ご飯食べてくつろいでからまたオフィスに戻って作業してた。3時過ぎに寝て8時に起きた。寝不足のせいか、今日も夕方に眠くなって家に戻って3時間ほど寝てた。

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

ストレッチ

今週もとくにお仕事で疲労や負荷はないものの、筋トレを継続しているせいか、やや腰が痛いかなといったところ。トレーナーさんによると、筋トレで筋肉痛になっていると体が硬くなるという。おそらくそのせいでやや硬めの印象になっているのだと思う。腰や太ももの前・後ろの筋に張りがあったのでこれらはスクワットの反動ではないかと思われる。今日の開脚幅は開始前152cmで、ストレッチ後157cmだった。先週と同じだ。

ハンガーラック受け取り

ジモティーで「ハンガーラック」を500円で購入した。これもコワーキングスペースで使う。この前帰ったときにジャケットを掛けるものがないと気付いた。引き取りに東灘区へ行く機会が増えてきてだいぶ道を覚えてきた。マンションの駐車場まで行って、そこでハンガーラックを受け取った。解体してくれていたので難なく荷室に積めた。丁寧な方で駐車場から車が出ていくときまでお見送りしてくれた。ジモティーだと受け渡しが終わったらすぐ帰る人の方が普通なので性格なのかホスピタリティの違いが出るなと思った。

iostat-tool のメンテナンス

日記を書こうと決めて初日に書いた内容 が iostat-tool の保守だったなと思い出した。2年半ほど前。一昨日からプルリクエストが届いていたのでレビューしたり、CI 環境の設定を更新したりしてマージした。

• Use %H for output generated with iostat -t #6

マージしてから 0.3.1 として https://pypi.org/project/iostat-tool/ にパッケージをアップロードした。

ファイナンシャルプランナーとの打ち合わせ

先週の続き 。17時からの予定だったが、プランナーさんの前の予定が早く終わったそうで15時半からに変更になった。お昼以降ならいつでもよいと伝えていたのでこういった調整ができてよいと思う。卓上カレンダーをお土産にもってきてくれた。今日は次のような内容を話した。

• 人生のキャッシュフローに問題ない
• 預貯金が多いのでもう少し運用にまわしたい
  • どういった運用があるのかノーアイディアなので提案してほしい
• 資産形成ではなく万が一のときのための役員向けの保険を提案してほしい

先方もどうせ来るならもっと準備して来たらいいんじゃないかとも思うが、次は teams でテレビ会議にしましょうと提案した。30分の打ち合わせのために三ノ宮のオフィスまで来てもらうのも申し訳なく思えてきた。その際にメールアドレスを伝えていて「すべて小文字ですか？」と聞くのでメールアドレス (ドメイン名) は大文字小文字を区別せず、大文字でも届きますよと教えてあげたら思いの外驚かれていた。昔からある古い仕様は大文字小文字を区別しなかったりする。大文字小文字を区別しないというのは、多くのケースで百害あって一利なしだけれども、互換性のために変更することもできない。

hugo のハンズオン資料作り

先日の打ち合わせ を受けて資料作りに着手した。hugo のサイト構築やテーマ設定は一度行ったらそうそう変更することはないので久しぶりに設定したら忘れていて、これどうだったかな？とか、このフォーマットはどこからきているのか？とか、いろいろ調べて思い出しながらやっていた。

hugo は設定ファイルを yaml, toml, json で記述できる。フォーマットを複数対応するというのはよくないということに気付いた。json はみたことないけど、テーマのサンプルの設定ファイルを yaml と toml の、開発者が慣れた方を使う。そうすると、テーマのサンプルの設定ファイルを yaml で提供していて、hugo.toml でサイトの設定をしていた場合、テーマの設定を yaml から toml に変換する作業が発生する。コンテンツの markdown も toml と yaml の両方で記述できるからフォーマットの統一感もなかったりする。なによりも初心者が調べたときに設定ファイルが toml だったり、yaml だったりして混乱する。

• Configure Hugo

デフォルト設定は toml になっているので hugo で yaml は使わない方がいいんだろうなと思えた。

さらに設定ファイルの名前も昔は config.toml だったのが、最近は hugo.toml に変わり、さらにどちらのファイル名でもよいという仕様になっている。こんなことになんの意味があるのかもわからない。

With v0.109.0 and earlier the basename of the site configuration file was config instead of hugo. You can use either, but should transition to the new naming convention when practical.

まずはサイト構築して github actions で github pages へアップロードする環境構築を完了した。

• https://t2y.github.io/hugo-hands-on/

徐々にコンテンツを追加していく。

0時に寝て3時半に起きてネットみたてたら6時半になってそれから寝て7時半に起きた。やっぱり生活のリズムがおかしい。

今日の筋トレは腹筋:20x1,腕立て:10x1,スクワット10x1をした。あと1kmほど散歩した。

go の RWMutex を使う

テストツールでちょっとしたプールを実装していて mutex を使うコードを書いた。書き込みはロックしないといけないけど、読み込みはロックする必要がないようなものは RWMutex を使うと普通の Mutex よりは読み込みが並行に動くので効率がよくなる。実際に RWMutex を使ってコードを書いたことがなかったので試しに書いて単体テストを実行して振る舞いを確認してみた。

type pool struct {
	l  []string
	m  map[string]struct{}
	mu sync.RWMutex
}

func (p *pool) exists(dn *ldap.DN) bool {
	p.mu.RLock()
	defer p.mu.RUnlock()
	_, ok := p.m[dn.String()]
	return ok
}

func (p *pool) get() *ldap.DN {
	p.mu.RLock()
	defer p.mu.RUnlock()
	length := len(p.l)
	if length == 0 {
		return nil
	}
	s := p.l[rand.Intn(length)]
	return mustParseDN(s)
}

func (p *pool) put(dn *ldap.DN) {
	p.mu.Lock()
	defer p.mu.Unlock()
	s := dn.String()
	p.l = append(p.l, s)
	p.m[s] = struct{}{}
}

4年ぶりの神戸ルミナリエ

たまたま 第29回 神戸ルミナリエ が1月の19日から28日にかけて行われるという記事をみかけた。そう言えば、いつも12月に開催されていたのが今回から1月に変わったみたい。毎年今回が最後みたいな含みをもたせて、なんやらかんやらでもう29回も続いているんやね。今回が第29回だからおそらく来年に第30回もやるのでしょう。「4年ぶりの開催が決定」と書いてあって、あれ？やってなかったっけ？と思ったらコロナ禍のために2020-2023年まで中止という意思決定はされていて、代替イベントとして小さいルミナリエっぽいイルミネーションをやっていたらしい。ルミナリエの展示場となる東遊園地がうちの近所なのでこれまでもやっていたような記憶があるのはそのせいかもしれない。今年は規模を拡張してやるのかな？久しぶりなので時間があるときに観に行ってみようと思う。

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

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

sveltekit のエラー制御

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

• sveltekit: エラー

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名は乗れるし、荷物も余裕をもって積み込みできる。このアイディアはいいなと思って、きのいえの定員もそのぐらいの人数がちょうどよさそうに思う。今回の開発合宿では人数の上限はどうかという点にも注目して取り組みたい。

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

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

sveltekit で context のデータを扱う

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

• context と共に store を使う

これだけですぐ動くのだけど、このときに 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