昨日は夕方から天気が崩れるという話しを聞いて夕方から家に戻ってゆっくり過ごしていた。ドラクエタクトやったりアニメの Dr.ストーンを見返したりしていた。

海外から輸入したときの会計処理と税金

昨日に引き続き、yubikey bio の設定や検証を一通りやって issue や記事にまとめていた。それが終わった後に会計処理についても調べていた。yubico 社の日本代理店はあるものの、指紋認証ができる yubikey bio の在庫を取り扱っていなかった。そのため、直接 yubico のオンラインストアで購入して日本へ発送した。インターネットで買いものをしているとあまり実感がないけれど、この場合は輸入手続きをして税関で関税を支払わないといけない。一方で用途が個人使用か商用利用かで関税がかかる基準額が変わってくる。これまでも個人使用で輸入して関税を支払ったことがなかったのは1.6万円以下のものは関税がかからないからだったんだと理解した。技術書ぐらいしか買ったことないけど。

• 少額輸入貨物の簡易税率
• 1006 課税価格の合計額が１万円以下の物品の免税適用について（カスタムスアンサー）

1万円以下の輸入については関税がかからない、且つ個人使用のものは商品代金の0.6掛けで金額を算出するという2つの法律の合わせ技で1.6万円みたいな中途半端な金額が基準になるらしい。当初は商用利用というのは自社ビジネスや転売のようなものを指すのかと考えいた。yubikey bio はうちの会社内で主に調査目的で使う。会社の経費で購入しているが、これは個人使用の範疇かと勘違いしていた。調べているとそれは誤りで 【輸入】個人使用と商用の線引き 法人輸入との違いは？ によると、業務やオフィスで使うことを前提にしているものは商用利用となるらしい。商用利用の場合は0.6掛けで金額を算定できない。yubikey bio は1万円ちょっと超えているので関税を支払わないといけない。

オンラインストアでの決済時に yubico 社は関税や輸送費を徴収しないと書いてあって本体価格しか支払っていない。調べていると、郵便局または輸送業者が関税を立替ているので商品を受け取るときに支払うという記事が出てくる。しかし、うちの郵便受けに商品がレターボックスで届いていたので私は関税と輸送費をまだ支払っていない。あれー？と思ってなにか手続きを誤ったのかどうかを調べ直したりしていた。おそらく輸送業者からまた後日、関税と消費税と輸送費の支払いに関する請求書が送られてくるはず。まだ届いていないだけなんだと推測する。もう少し待ってみる。

• 個人輸入通関手続

輸入したときの会計処理も通常の取引登録とはまったく異なっていてまた1つ税金の勉強になるなと分かって楽しみにしている。また後日、輸送業者から請求書が届いたときに輸入したときの税金を精査してみる。

3時半に寝て7時に起きた。リリース終えたので晩ご飯を食べてから自分の会社のお仕事をしていたら遅くなった。

ストレッチ

今週もリリース明けでそれほど座っている時間が長かったわけでもないため、腰の張りはあまりなく、負荷は低くなっているのではないかと推測する。今日の開脚幅は開始前156cmで、ストレッチ後158cmだった。右股関節周りの硬さは相変わらず大きく変化はないが、他がよくなった分、右ふともも前の筋を伸ばすと張りがきつくてしんどいように感じた。しばらく余裕のある生活ができるので歩いたりストレッチしたりする余裕が出てくるかもしれない。

yubikey bio を触ってみた

先日 yubikey bio をオンラインストアで購入 した。会社の経費で業務で使うことを目的に購入したのでこの場合は商用利用の輸入にあたる。また別途、輸入についての会計処理を書く。yubico はスウェーデンの会社でどうやら日本向けはスウェーデンの首都ストックホルムから発送されてきたらしい。安いエコノミープランで注文していた。発送メールを受け取ったのが 4/17 でオフィスの郵便受けに入っていることに気付いたのが 4/29 になる。12日で届いたことになる。船便にしては早いからなにかしら航空便の安いプランで届いたのだと推測する。

Economy - 10-20 Working Days - No tracking available

早速、接続していろいろ触ってみた。結論から言って ubuntu 22.04 で fido2 pin を設定して u2f を使って2要素認証のメソッドとして pam や web アプリケーションから問題なく使えた。ubuntu 向けのアプリケーションも ppa のリポジトリを追加して apt からインストールできる。

• Installing Yubico Software on Linux

このドキュメントには次の4つのアプリケーションのインストールが書いてある。

• YubiKey Manager (CLI): sudo apt install yubikey-manager
• YubiKey Personalization Tool: sudo apt install yubikey-personalization-gui
• libpam-yubico: sudo apt install libpam-yubico
• libpam-u2f: sudo apt install libpam-u2f

yubikey は他にもいろいろな認証の用途に使えるらしい。今回は fido2 の設定のみを紹介する。fido2 pin を登録するには YubiKey Manager の GUI を使った方が簡単なので次のアプリケーションも一緒にインストールするとよい。

$ sudo apt install -y yubikey-manager-qt
$ ykman-gui

おそらく ykman の cli でも登録できると思うけど、yubikey や認証設定に慣れていない初心者は gui のナビゲーションに従って作業して結果を確認した方が安心だと思う。fido2 pin は ssh でいうところのパスフレーズのようなものなのかな？デバイスが盗まれるのを防ぐために pin があるという。一方で web アプリケーションが fido2 で認証するときに pin を要求するかどうかは任意になるらしい。よくあるパターンは初めて使うときは pin を要求して2回目以降はスキップするといった用途が多いのではないかと推測する。

この fido2 pin を使って Universal 2nd Factor (u2f) の設定を行う。

$ mkdir -p ~/.config/Yubico
$ pamu2fcfg > ~/.config/Yubico/u2f_keys
Enter PIN for /dev/hidraw3: ***  <= このときに yubikey manager で設定した fido2 pin を入力

この後 yubikey デバイスが点滅するので丸いセンサー部分を指でタッチすると完了する。このときに指紋登録しているのか、物理的にタッチすることを要求しているだけなのか、よくわかっていない。この前に chrome で指紋登録 をしていたのでそれが使われているのかもしれない。いま ykman で設定をみたら Fingerprints registered とあるのでどこかしらに指紋登録されているらしい。おそらく chrome じゃないかと推測する。

$ ykman fido info
WARNING: PC/SC not available. Smart card (CCID) protocols will not function.
PIN is set, with 8 attempt(s) remaining.
Fingerprints registered, with 3 attempt(s) remaining.
Always Require User Verification is turned on.

linux で認証時に u2f を使いたいときは pam_u2f.so を使って pam の設定をするとよい。ubuntu だと /etc/pam.d/ 配下にいろんな認証設定がある。例えば login 時に2要素認証をしたい場合は次のようにフックする。パスワード入力した後に yubikey のセンサーを物理的にタッチして指紋認証を行える。セキュリティに厳しい会社はこういった運用をしているのかもしれない。

$ sudo vi /etc/pam.d/login
...
# Standard Un*x authentication.
@include common-auth
auth       required    pam_u2f.so

パスワード認証の代替として使いたい場合は通常の認証の前に sufficient として呼び出せば指紋認証が成功したときにそれ以降の処理がスキップされる。

auth       sufficient    pam_u2f.so
@include common-auth

これらの設定を確認にするには pamtester というツールを使うと簡単にできる。認証の設定を誤るとログインできなくなってしまうので慎重にテストして振る舞いを確認した上で実際の運用を行うとよい。

$ pamtester login t2y authenticate  <= このときに yubikey デバイスが点滅するので指紋認証する
pamtester: successfully authenticated

せっかく購入したので 1password アカウントや github の2要素認証に設定してみた。ワンタイムパスワードの otp の代替として使える。ワンタイムパスワードを入力するより yubikey のセンサーをタッチする方が日々の運用としては少しお手軽と言える。設定していて otp と yubikey でお互いに2要素認証のバックアップを兼ねることに気付いた。認証方法が増えるのでセキュリティ的には脆弱になるけれど、サービスとセキュリティのトレードオフの考え方から、yubikey の分だけ脆弱になっても物理的なセキュリティを担保できるのであれば利便性を考慮してよいように私には思えた。

今週は19時に帰ってきてそれから晩ご飯を食べて家でくつろぐという生活に戻ってきた。生活に余裕をもてるようになってきた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。先週はリリース前の余裕の無さからお休みしたので1ヶ月ぶり。今日の議題はこれら。

• 第4期のふりかえり
• デザイナーさん向けの発注や契約の話し

先週末にふりかえり資料の叩き台を作って洗練させた資料を説明していたら1時間ほどかかった。もう3年会社を経営したので財務や経営についてわかったことがたくさんある。会社の貯金もある程度貯まって財務が安定してきた。無知の無知が怖かったので創業以来、財務に注意を払ってきた。しかし、これから業務がプロダクト開発へ移行していくに当たって財務のことを気にかける必要はないと私は考えている。そんな油断をしていると足元をすくわれるのかもしれないが。

業務委託の契約の話をしていて、請負契約と準委任契約の違いについて話題になった。うちは創業以来、準委任契約でしか働いてきていない。ipa が公開している 情報システム・モデル取引・契約書（アジャイル開発版） でもアジャイル開発は準委任契約を推奨している。私も開発プロジェクトに入って柔軟に開発するスタイルを好むことから相性がよかった。うちの会社は準委任契約のメリットを十分に理解できている。

準委任契約のメリット

• 成果物の取り決めがないので納期へのストレスや開発遅れに対するリスクが小さい
• がんばって働けば人月単価の金額が毎月売上としてあがる

準委任契約のデメリット

• 普通のサラリーマンと働き方がほぼ変わらない

はらさんと話していてとして請負契約の特徴として次のようなことが上がった。

請負契約のメリット

• 請負契約の方が儲かる可能性がある
• 自分たちが実際に作業しなくても協力会社に発注できる

請負契約のデメリット

• 成果物ができないと売上が上がらず利益率が悪化したり、赤字になるリスクがある
• 納品しないと売上が立たないので資金繰りが難しい

私の基本的な姿勢として協力会社に開発の業務を発注したくない。とくに品質レベルを知らない協力会社に発注することは100%ない。それは私が sier 出身なので他社へ開発を発注するときの難しさや管理のしんどさをよく知っているからだ。私が sier を辞めた理由の1つに自分がミスしたわけでもないのにお客さんに謝り続けるのが嫌になった。開発を他社へ依頼するとそこで発生した不具合やトラブルのすべての責任をもたないといけない。自分がミスして迷惑をかけて謝るのはなにも苦にならないが、他人がミスしたものを自分の責任として謝るのが当たり前の生活をやっていると、私の方がもっとうまくやれんじゃないかと考えてしまったりした。1人だと開発はスケールしないが、他人が品質の低いもの作ってしまうのと比べて開発の満足感が違う。

いずれにしても請負契約は双方に体力がないと資金繰りが厳しくなってお互いにリスクがある。

また資金調達の手段としてのクラウドファンディングは複数の側面があっていいんじゃないかという話題も少し盛り上がった。少し前に私もいとうさんのプロジェクトの応援のために支援した。800,000円という目標金額に対して残念ながら665,540円と未達ではあったものの、76人もの支援者がいることがわかる。私がクラウドファンディングのプロジェクトを作ってもおそらく支援者はよくて数人といったところだろう。いとうさんのメディア力であったり信用のすごさがわかる。クラウドファンディングやってますというのが支援することに関心がなくてもシェアするだけで開始前からマーケティングメッセージになる。そんなプロジェクトがあるんだというのを知ってもらうだけでも大きなことだと思う。

• 全国のコワーキングをネットワーク化しイベント情報の共有と収益の分配を実現したい！

開発合宿の計画づくり

昨年度に workcation と称して行ってきたイベントを今年度も行う。いとうさんから2泊3日のようなちゃっちいイベントをワーケーションと呼んだりしないと教えてもらったので今年は開発合宿と呼ぶことにする。タグも新規に camp に付け替える。前回は6月という閑散期に行って空いててよかったのだけど、今年は最も賑わうという冬の繁忙期に行ってみたい。夏と冬だと情緒も変わるはずなので私にとってどちらがよいかも判断してみたい。身近な人たちから声をかけて、昨年は4人だったが、最大13名泊まれるそうなのでもう2-3人ほど増えてもいいんじゃないかと思ったりしている。まずは日程調整からしていかないといけない。

• 冬の城崎温泉へようこそ！

22時に寝て0時に起きてやや吐き気で苦しんで4時に起きて7時に起きた。夜遅くに食べてないのに調子悪かった。

docker image のマルチプラットフォーム対応

やぎさんが docker buildx でマルチプラットフォームのイメージを作成する の記事を書いてて buildx プラグインがあることを知った。ちょうどいまお仕事でコンテナベースのプロダクトを開発している。まずはオンプレミス向けが対象なので amd64 でビルドしていた。今後はクラウド向けにも提供していくので arm64 ビルドもいずれ追加しないといけないと考えていた。ちょうどリリースを終えて調査時間の余裕があるのでこの機会に buildx について調べてみることにした。

Docker Engine 23.0 release notes をみると次のように書いてある。

• Set Buildx and BuildKit as the default builder on Linux. moby/moby#43992
  • Alias docker build to docker buildx build. docker/cli#3314
  • The legacy builder can still be used by explicitly setting DOCKER_BUILDKIT=0.
  • There are differences in how BuildKit and the legacy builder handle multi-stage builds. For more information, see Multi-stage builds.

23 からデフォルトのビルダーとして buildx が使われるようになっているらしい。Building multi-platform images を一通り読んで試してみた。

buildx ではカスタムビルダーを定義して複数プラットフォーム向けの docker image を一緒にビルドできる。このとき個々のビルド環境を builder instance と呼び、ビルド環境を抽象した概念として扱われている。マルチプラットフォーム対応の文脈で言えば amd64 や arm64 のビルド環境をそれぞれに作る。例えば amd64 のマシン上で arm64 のビルド環境を作るときは qemu を使ってエミュレーションしたビルド環境を用意したりもできる。builder instance はカスタムビルダーで制御する。

$ docker buildx create --name mybuilder --platform linux/amd64,linux/arm64
$ docker buildx ls
NAME/NODE    DRIVER/ENDPOINT             STATUS   BUILDKIT PLATFORMS
mybuilder    docker-container
  mybuilder0 unix:///var/run/docker.sock inactive          linux/amd64*, linux/arm64*

ここで作ったカスタムビルダーの driver は、デフォルトビルダーの docker ではなく、docker-container になる。おそらく builder instance の実体であるビルド環境がコンテナ上に構築されるのだと思う。これらの builder instance を使ってビルドされる。カスタムビルダーをデフォルトで使うには次のように実行する。

$ docker buildx use mybuilder

このカスタムビルダーを使って docker image をビルドする。カスタムビルダー側にプラットフォームの設定をもっているので --platform は指定しなくてもよいけど、明示した方がわかりやすいだろう。

$ docker buildx build --platform linux/amd64,linux/arm64 -t myimage:latest .

ビルドの処理は進んでいたが、正常終了しなかったので途中でやめた。なにか設定の漏れがあるかもしれないが、だいたいの雰囲気はつかめた。

ここでいま gitlab ci/cd 環境では kaniko というツールを使って docker image をビルドしている。そもそも kaniko と buildx の違いもわからなくなって README を読み返すと次のようなことが書いてあった。

kaniko は Docker デーモンに依存せず、Dockerfile 内の各コマンドを完全にユーザースペースで実行します。これにより、標準的な Kubernetes クラスタのように、Docker デーモンを簡単かつ安全に実行できない環境でもコンテナイメージを構築することができます。

ローカルで検証しているとしばしば忘れてしまうが、docker cli を使うには docker daemon を起動しておかないといけない。ci/cd におけるビルド環境がそもそも dokcer で動いていたりすると docker daemon を使えるかどうか (dind: docker in docker) はセキュリティ上の大きな違いになってくる。ci/cd 環境によっては docker daemon が使えないという状況はありえる。そういった環境でも docker image をビルドできるのが kaniko のメリットと言える。

kaniko はマルチプラットフォーム対応なビルドができるのかどうか？issue でもそういった質問がいくつかみつかる。

• how to build multi-arch image using kaniko #786
• Multi architecture build with only Kaniko #1746

結論から言うと、kaniko そのものはマルチプラットフォーム対応のビルド機能をもっていない。アーキテクチャごとのビルド環境があればそれぞれビルドするだけになる。しかし、マルチプラットフォーム対応の docker image というのは manifest list というのを作ってコンテナレジストリに push すればよいという仕組みらしい。この manifest を作るためのツールとして manifest-tool というのがある。このツールと組み合わせれば、kaniko でもマルチプラットフォーム対応の docker image をコンテナレジストリに登録できる。実際に試したわけではないので想像で書くが次のような手順だと推測する。

1. kaniko でそれぞれのプラットフォームの docker image をビルドする
   1. amd64 向けにビルドする => latest-amd64
   2. arm64 向けにビルドする => latest-arm64
2. ビルドされた複数プラットフォームの docker image に対して manifest-tool でコンテナレジストリに push する
   1. latest- prefix のタグをもつ docker image の manifest list を作る
   2. manifest list を使ってコンテナレジストリへ push する

ci/cd 環境でこういった手順のパイプライン処理やジョブを定義して実行すれば kaniko でもマルチプラットフォーム対応な docker image を push できると思う。

1時に寝て何度か起きて7時に起きた。昨日は23時半に帰ってきてから十割蕎麦を茹でて食べたけど、吐き気はなかった。蕎麦ぐらいなら大丈夫か。

開発方法論の見直し

開発が一区切りしたタイミングで開発方法論やガイドのドキュメントも見返して、過去に作ったときからみて現状の内容や気付き事項などを加筆修正していた。これを繰り返すうちに開発文化が言語化できていく雰囲気はする。その後は issue の洗い出しや1on1 やってインストール手順の検証やドキュメントの更新などをしていた。これと言って成果を出した一日ではなかったものの、wiki をあちこち更新して整理していたらいつの間にか時間が過ぎていたという所感。

歯科検診

17時から歯科検診へ行ってきた。いつも通り歯のお掃除をして1年ぶりに歯のレントゲンを撮ることになった。新たにレントゲンを撮る機械が導入されていて、台に顔を置くとカメラが顔周りを移動してレントゲンが撮られた。これまでは位置固定のための器具を噛んでパシャパシャ撮るやり方だったので面倒だったのが便利になっていた。帰りにカードリーダーが置いてあることに気付いて、受付の担当者さんに尋ねたら、マイナンバーカードに保険証を設定すれば使えることを教えてもらった。次回はマイナンバーカードで保険証提示をやってみたい。

0時に寝て6時半に起きた。朝起きてからドラクエタクトしてた。

リリース

今日がプロダクトのリリースとなる。先週前半にはテストを完了して開発作業も終えてインフラの整備やドキュメントの作成に注力してきたのでここ数日の様子をみれば無難に順調にリリースできたようにみえる。結果からみれば「余裕でしたね」とコメントされても大きく外れてはいない。6ヶ月でやってと言われた開発を、3ヶ月目に5ヶ月でできると勝手に短縮して、4ヶ月目にやっぱ間に合わないからもう1ヶ月待ってと6ヶ月に戻した。一人時間差攻撃みたいなマネジメントをして完了した。ここ2ヶ月ほど私がいくつか開発やデバッグを肩代わりをして開発の下支えをした。別に私がやったらいけないという制約はないけれど、メンバーの教育も含まれているプロジェクトなのでなるべくメンバーが経験を積んでスキルを磨くのが望ましい。この件はちょっとズルしましたと進捗報告している。まずはうまくいって安心した。

ともあれ、私がプロジェクトマネジャーという肩書きをもって臨んだプロジェクトで概ねスケジュール通りに開発を進捗させてお客さんの要件にあったプロダクトを作り上げたことそのものが、私のキャリアにおいても重要なことであるし、うちの会社では課題管理という分野をビジネスの中核にしていく上での最初の実績として大きな意義のあるプロジェクトだった。課題管理はチーム開発において強力な武器になる。これまでの自分と、そう大きく変わらない働き方をマネージャーでやっても結果を出せたことは自信にもつながる。

この後は6ヶ月間の大きなふりかえりも控えていて、課題管理に溜まったデータを分析して、次開発への改善などにもつなげていこうと思う。過去の経験則では課題管理の価値を実感してもらうのに半年はかかるというのが私の持論。それは比較的、最初から課題管理システムを使えていたうちのチームでも同じだと思う。私がやっている課題管理とメンバーのそれとの違い、その違いによる実際の業務における成果などを分析していくと示唆を与えられるのではないかと思う。

22時頃から寝て何度か起きて7時に起きた。久しぶりに夢をみた気がする。オフィスに着いた頃にはもう覚えていないけど。

リリース前日

プロダクトの開発、テスト、パッケージングとすべて完了していてドキュメントや社外に提供するためのインフラの仕組みの作業を行っている。これはリリースまでに出来ていなくてもプロダクトが動かないわけではないのでリリース後もしばらくは継続する。今日は運用ツールのちょっとしたリファクタリングをしたり、コードレビューをしたり、windows インストーラーの調査をしたりと、なんやらかんやらで忙しかった。

示唆を与えなければならない

ここ1ヶ月ほど私がクリティカルパスの作業を担ってきたのでメンバーの作業を落ち着いてみる余裕がなかった。たまたまというか、私がクリティカルパスから脱したことでメンバーのレビューやアドバイスを行うときの余裕も戻ってきた。CSK の新人研修で習うことに社是と経営理念とサービス精神という言葉がある。

サービス精神

• お得意様にあくまでも満足していただく技術を提供しなければならない
• 技術は高度で専門的でなければならない
• 仕事は正確に、かつ迅速・効率的に行なわなければならない
• 常に、お得意様の利益を考え、示唆を与えなければならない

新人研修ではこれらを暗唱して暗記させられる。20年以上経ったいまでも覚えている。もともと私の考え方にあっていたのか、それとも新人の頃に刷り込まれたのか、その両方なのか。いま見返すと私の課題管理の考え方とこのサービス精神には共通しているところもある。その上で最後の 「示唆を与えなければならない」 という言葉を、今日メンバーとやり取りしているときにふと思い出した。

アドバイスをしていると、なぜこの懸念を考えずに作業を継続してしまったのだろうか？と思う機会がちょくちょくある。そのときに質問してその背景を尋ねたり、効率や保守のための考え方を教えたりする。ふと私が指摘しなかったらそういった効率や品質の低い結果のまま進んだのだろうと推測される。当たり前の話しだが、意識的にしろ無意識にしろ、個人では気付けなかったフィードバックや示唆を与えてくれる人がいなかったら個人の能力では限界がある。気付きがないところに学びも改善もないから成長もしない。いまお手伝いしている会社はこれまで個人でやってきた働き方を、チームで協調して働くように変えていきたいという話しから始まった。私自身、どちらかと言えば個人主義の働き方をしてきた方でチームでの働き方をちゃんと教えられるか、当初はあまり自信がなかった。半年やってきて、チームで働く上で必要なことはメンバーのアウトプットに対して質問するだけでよかったんやと理解できるようになってきた。個人の視点しかない働き方と他者の視点から常にツッコミが入る働き方はまったく異なる。うちのメンバーをみていて、まだまだ道半ばではあるが、それまでの状況と私が啓蒙している課題管理は、おそらく根本的に働き方を変えてしまっていることにようやく私の理解が追いついてきた。

0時に寝て6時に起きた。午前中は掃除したり買いものへ出掛けたりムック本を買って読んだりして午後からもくもく会に参加してきた。昨日から休日って心地よくて素晴らしい時間だということに改めて気付いた。

いまがわかる地政学

やぎさんからおすすめされて オールカラー図解 いまがわかる地政学 を読んだ。ちょうど余裕もあったので読んでみることにした。私も過去に地政学の雑誌を気分で買って読んだことがあった。教えてもらってなければいまは買ってなかったと思うが、関心のある分野ではある。

見開きの2ページで左ページを地図で図解しながら右ページにその説明が書いてある。読み始めてすぐにドキュメントランドスケープを構築できるので読みやすい。地政学なので地図で説明するのがわかりやすいのと、特定の地域の限られた国で、且つ話題を限定して説明するから簡潔でわかりやすい。過去にはアメリカ／イギリス系統とドイツ系統の2つの地政学があり、地政学はナチスドイツの御用学問となり、ドイツが敗戦したことによりドイツ系統の地政学は封印指定された。日本で学ばれていた地政学もドイツ系統だったようで、戦後 GHQ により封印指定されていまに至るらしい。

地政学の解説を読んでいて、なにかを分類して、そこから得られる知見に方向性や解釈を与えて、さらに歴史が積み重なると立派な研究や学問になるという印象を受けた。観察して分類して仮説を立てて記録を取り続けるとそれはもう科学である。課題管理につながるヒントもありそうな気がしている。課題管理は事象が発生した記録を取り続けて、ある程度溜まったところで分類したり分析したりできる。

もくもく会

【三宮.dev オフライン】もくもく会 に参加した。昨日の続きでプロダクトのドキュメントを2時間ほど書いてた。集中してドキュメントと mermaid のフローチャートを書いた。初めて参加された方も何人かいたのでいろんな人の話しを聞くこともできてよい機会だった。参加者の1人から 芋屋HUG のスィートポテトをもらった。お店の存在は知っていたが、1度も買ったことがなくて初めて食べておいしかった。調べてたら神戸発祥のお店っぽいので東京出張するときのお土産に買って行ってもよさそう。よいお土産を知ることができてよかった。

昨日は夜に晩ご飯の買い出しにオフィスを出てから、また戻って作業して22時頃に帰ってきて0時に寝て7時に起きた。今日はここ1-2ヶ月では久しぶりにプロジェクトの締め切りに追われずに落ち着いてやりたいことができた。

ストレッチ

先週に比べれば負荷は減っていたので右腰の張りは少しよくなった。むしろ先週が悪過ぎた。いつも通り右足全般は張りがあるのと、お尻と太ももの境界のツボもいつもより効く感じがして辛かった。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。リリースに向けての根を詰めてやってきた作業も一段落したのでこれからは体調をよくする方向に意識を向けていけるかもしれない。

プロダクトのドキュメント

追われてないので余裕をもって昨日の続きで2時間ほど書いてた。3 (ページ) ファイルを追加した。ドキュメントは一気に書くとしんどい。少しずつ書いていけば徐々に文量が増えてさらに内容も洗練されていく。休日にドキュメントを書いていると途中で割り込みが入らないから集中できて効率がよい。ソースコードにしろ、文章にしろ、書くときに割り込みが入らない状況は重要なことに最近気付いた。この日記もまとめて数日分を (下書きから) 書くときがあるが、それは集中して書ける時間を取れそうと見計らって書いている気がする。どうやら私は割り込みの有無と書くときのモチベーションに相関関係があるように思える。

きんとん

夕方にたまたま出掛けて、よく行くお店で晩ご飯食べようと思ったら開店の20分前で諦めて帰ろうとしていたときにたまたま目にとまった。以前から人気のあるお店であることは知っていたし、いつか入りたいと思っていたお店で、中途半端な時間帯だからお客さんも少なくて、いまがその「いつか」だと気付いて きんとん 神戸店 に入ってみた。後で食べログのとんかつ百名店2022の1つであることを知った。昔からあるから古いお店だと思い込んでいたけど、実際はそうでもなく、店内はオープンでモダンな佇まいで少し驚いた。特選ロースかつ定食が1900円。ちょっと高め。おいしかったので十分に満足した。タレもとんかつソース、わさび醤油、ヒマラヤ岩塩があって、それぞれに味わいがあってよかったし、キャベツにかけるドレッシングもオリジナルでおいしかった。接待にもよさそう。

第4期のふりかえり

年度が変わって1ヶ月が経とうとしている中、ようやく昨年度のふりかえりができる状況になってきた。今年は3月に余裕がなくて少し後ろにずれ込んでいる。この年度ふりかえりも毎年やっているから知見も溜まっていくし、新しい発見もある。来週の雑談に向けてまずは叩き台を作った。もう2-3日ほどかけて資料を洗練させていく。

一昨日あまり寝てなかったので昨日は早く帰ってきて20時から22時ぐらいまで寝て、その後0時ぐらいから寝て何度か起きて7時に起きた。久しぶりによく寝た。

プロダクトのドキュメント

プロダクトのインストールや設定のドキュメントを mdBook で書いている。チームのメンバーが reStructuredText を知らないというので markdown で書ける方がいいかと思って採用した。4月上旬から環境作り して時間のあるときに少しずつ書き足したり、メンバーにも書いてもらうように促したりしていた。情報としてはだいたい半分ぐらい書けたかなぁといったところ。まだまだ内容は足りていない。

内容とは別に、ある程度まとまったドキュメントとしてのわかりやすさを、例えば Sphinx のようなツールと比較してどうかというのを書き終えたら比較してみようと思う。1つ懸念点としてわかったことに SUMMARY.md からリンクされていない md ファイルはレンダリングされないという仕様になっていて、この仕様の是非や目次の作り方の構成に制約が課せられることへの懸念がある。次の issue でも議論されている。

• It is recommended that all md files in the directory be converted to html #830
• Files not in SUMMARY.md are not parsed #702

mdbook は私が想定したほど普通のドキュメントツールが備えているような機能を実装していなくて、それは markdown を独自拡張したくないという意志なのかもしれないけれど、本当に最低限の体裁だけでドキュメントのようにみえるようにするといったところしか関心がないのかもしれない。ちょっと触った雰囲気でも本格的なドキュメントを書くツールではないと感じている。私がまだわかっていないだけかもしれないのでもうちょっと触ってみてまた所感をまとめる。

チーム勉強会

2週間ぶりのチーム勉強会。メンバーが Stable Diffusion の話しをしてくれた。学生時代に関連する研究をしていたらしい。本人は研究していたから内容を理解しているのだろうけど、一般人の私には全然ついていけなくて説明そのものが難しいなと思いながら聞いていた。そして、最近の研究成果などを紹介しながら15分ぐらいで終わった。論文の内容を理解できているのなら、その内容を解説してもよかったのでは？と思ったりもした。1時間の枠があるのだからもっと話してもらってよかったのだけど、準備も大変だったのかもしれない。時間が余っていたので私がモデレーターとして質問したり、他の参加者に質問を促したりしながら残り時間の40分ほど雑談していた。そういう意味では雑談会としては多くの質問やコメントが出てよかったと思う。意図的に発表時間を短くして雑談会にもっていくというやり方もあるのかな？と勉強会の運営の学びにもなった。

2時に寝て7時に起きた。昨日も遅かったので0時ぐらいに晩ご飯を食べてうまく眠れなかった。体調が悪かったので今日は早めにお仕事を終えて帰って寝てた。

rpm パッケージングのためのアーカイブ

プロダクトは docker compose を使ってデプロイするので docker-compose.yml と関連する設定などのサンプルファイルをパッケージングして rpm として提供する。ビルドは必要なく、初期は数ファイルだったので rpm の SOURCES ディレクトリに直接配置して個別に SourceXx と指定してパッケージングしていた。設定のサンプルファイルが増えてくると1つずつ指定するのが面倒になってきてアーカイブすることにした。rpm を作るための Makefile で次のように git コマンドからアーカイブを作ることができる。このやり方のメリットの1つは git でアーカイブすることでリポジトリにコミットされているものだけが使われるため、対象ディレクトリに中間ファイルなどが散らかっていても無視してくれて都合がよい。

VERSION          = 1.0.0
SRC_PREFIX       = my-product-$(VERSION)
SRC_ARCHIVE      = $(SRC_PREFIX).tar.bz2

SOURCES/$(SRC_ARCHIVE):
	git -C ../my-src archive HEAD --prefix $(SRC_PREFIX)/ -o $(SRC_ARCHIVE)
	mv ../my-src/$(SRC_ARCHIVE) $@

make したときに my-product-1.0.0.tar.bz のようなアーカイブが rpm パッケージングするときの SOURCES 配下に置かれる。そして rpm の spec ファイルでこのアーカイブを Source0 として指定して %prep で %setup マクロを呼び出すと展開される。

Source0: my-product-%{version}.tar.bz2
...
%prep
%setup

たったこれだけで spec ファイルの Source 管理をシンプルにできて保守コストが下がるのでうまいやり方だなと学びになった。