1時に寝て何度か起きて7時に起きた。能の本を読みながら寝落ちした。新しい開発のマイルストーンに入って、初日からいくつかリファクタリングしたり、コードレビューしたりしていた。開発が始まったなーって感じ。

能―650年続いた仕掛けとは―

少し前から 能―650年続いた仕掛けとは― を読み始めている。読んでいておもしろいので参考になりそうなことや気付いたことを忘れないように書いておく。著者の安田さんは能が本当に好きなんだなというのが伝わってくる文章で好感がもてる。

はじめに

著者が能のとりこになったきっかけが書いてある。最初に観た舞台で著者は「幻視」を体験したという。著者は高校教師であったが、能の師匠に弟子入りして週末に習い始め、その後、能楽師としてプロになったという。著者が能の歴史を調べるうちにいまの社会は能から大きな影響を受けていると気付いた。たしかに650年も続いているのだからそれは容易に想像できる。個人的にこの序文は見事な内容だなと思う。私が本書に興味をもったのもこの序文の秀逸さを感じたから。

第一章 能はこうして生き残った

能は室町時代に観阿弥・世阿弥によって大成された芸能になる。それまでも猿楽や田楽と呼ばれていた芸能ではあるが、それらを洗練させ、ときの将軍の庇護もあり大成に至ったらしい。

初心忘るべからず

いまでも知られている世阿弥の有名な言葉であり、一般的には「始めたときの気持ちを忘れてはいけない」といった意味で使われる。それ自体も誤りではないが、世阿弥自身はそのような意図で使っていたわけではないらしい。

「初心」という言葉にも深い意味があり、変化が起こったときの境になる状況や心境を「初心」と表している。人は生きている限りさまざまな変化を経て成長していく。そのところどころに過去の自分を断ち切らないといけない状況がある。その断ち切りには痛みを伴うが、成長のためには避けて通れない。その選択を突きつける境こそが「初心」なのだという。

能の稽古にもその仕組みが含まれていて、稽古で師匠は決して弟子に及第点を与えることはない。ただ「ダメだ」と言うだけ。弟子はなにがダメかも分からず練習に励み、その状態で本番の舞台を迎えて、練習でダメなのだから本番でもうまくできなくて不本意な結果に終わるものの、本番を迎えたことでなにかしらその人の壁を乗り越えているはずだとみなす。舞台の前後におけるその人のなにかの変化を「初心」というらしい。そして、能を習う人はなにかしら新しい挑戦に立ち向かい、「初心」の壁を破ったときにある変化の快感を忘れられなくて能にはまるという。

第ニ章 能はこんなに変わってきた

能の歴史は次の4つに大別されるという。

1. 形成期 (奈良時代〜)
2. 大成期 (室町時代〜)
3. 展開期 (戦国時代〜)
4. 式楽以降 (江戸時代〜)

能の起源は、奈良時代に唐の大衆芸能である散楽 (さんがく) が日本に入ってきて、それが猿楽 (さるがく) になったとみられている。一方で日本古来の神楽 (かぐら) にも影響を受けている。世阿弥も「猿楽はもとは神楽なのだが、」という件を書き残しているらしい。世阿弥は能の始祖として 秦 河勝 (はた の かわかつ) という人物をあげている。

戦国時代の能への大きな貢献は豊臣秀吉だという。秀吉が能に凝って推奨したことで劇的に広まったとみられている。

第三章 能はこんなふうに愛された

江戸時代に入り、家康も秀忠も能を好み、家光・家綱の頃から式楽として定着し、大きな影響を与えたのが5代将軍の 綱吉 だという。生類憐みの令で有名な犬好きな将軍であるが「能狂い」と言われるほどの能を好んだ将軍であったという。将軍が並々ならぬ熱意で能を推奨するので大名や家臣も能を学ばざるを得ず、諸藩でも能が学ばれるようになっていったという。おもしろいのが能が盛んな藩は外様であり、譜代代表や徳川家の血筋である松平家ではあまり盛んでないことから関係性の厳しさも伺える。そんな背景もあり、武士の教養の1つとして能を学ぶようになっていった。また庶民にも 謡 (うたい) という能の詞章を謡うことが広まり、寺子屋でも教えられ、庶民の教養の1つになっていったという。大工さんの棟上げ式、縁起ものを納めるとき、結婚式などで謡われたという。

2時に寝て何度か起きて7時に起きた。能の本を読みながら寝落ちした。

落ち穂拾いの終了

4月末にリリースしてその後 GW に入って、5月は「落ち穂拾い」として 開発全体のふりかえり をやったり、次の開発の要件を整理 したりしていた。ドッグフードテスト の導入もまだ作業中ではあるが、社内のシステム管理者にも協力していただいて進めている。私の作業でも十分な余裕をもって次の準備につなげることができたので開発の区切りで1ヶ月ぐらい準備期間があることはよいように思える。経営者はもっと働かせたがるかもしれないが。

これまでの開発は定例会議も 1on1 も毎週行ってきたが、次の開発ではこれらの会議を隔週にしてみる。口頭による同期コミュニケーションのコストを減らし、より開発そのものに時間を割いて注力できるようにする。もしかしたら、これによって私も開発に参加する時間を作りやすくなるかもしれない。もう1つ 必要なときに必要な人とすぐに話す (会議の日まで待たない) という狙いがある。毎週会議があると、すぐ聞けばよいことを次の会議まで待ってしまうということがある。私もある。私ですら待つときがあるのだからおそらくメンバーにもそうしてしまうことがあると推測する。会議の頻度を下げることでこの待ち時間を削減して即時問い合わせ、即時解決するといったコミュニケーションに移行していきたいという狙いがある。開発者の自律性を高めるためにはこういった取り組みも必要だと思える。もっと言えば、毎週会議しないと情報共有できないというのは開発者を子ども扱いして堕落させるのではないかと考える。実際に意図したようにうまくいくかどうかはやってみてから考える。

うちの開発メンバーは半年前より見違えて課題管理に習熟したので次の開発がどうなるかが本当に楽しみだ。

0時に寝て何度か起きて7時に起きた。署名・押印を完了した相続の書類を朝一で郵便局へ言って送付した。これで後は弁護士さんや司法書士さんが残りの手続きをやっておいてくれるのかな？少し気が楽になった。

ラップしたエラーのチェック

java でいうところの Chained Exceptions を go では Wrap という概念で表現する。Unwrap する interface を提供することで事実上の Chained Exceptions と同じようにオリジナルのエラーを辿ることができる。go はオブジェクト指向言語ではない と先日の勉強会でも念押し確認してエラーの型階層という概念はないが、Wrap をみていると型階層の方が自然じゃない？と考えられなくもない。言語の設計を考えるよいお題だと思えた。

エラーチェックについては次の記事がわかりやすかった。

• Go の自作エラーを errors.Is と errors.As で wrap 元のエラーと識別するときには、Unwrap も実装しよう

カスタムのエラーを定義する。

type MyError struct {
	message string
	err     error
}

func (e *MyError) Error() string {
	return e.message + ": " + e.err.Error()
}

func (e *MyError) Unwrap() error {
	return e.err
}

このチェックのために errors パッケージに次の2つの関数がある。

• errors.Is: エラーのインスタンスが同じかどうか
• errors.As: エラーの型に代入可能かどうか (事実上はインスタンスの型が同じかどうか？)

たしかにこれでもすぐに実装できた。型階層なんかなくてもこれで十分でしょというのが go の意見かな。

隔週の雑談

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

• サイトデザインの話し
• 能をみにいく話し
• 冬の開発合宿の話し

週末は勉強会と実家に帰るので余裕がなかったのであまりネタがなかった。能の話しをしていて、子どものときに関心がなかったものを大人になって受け取り方が変わるものがあるのはなぜか？という話題で雑談した。はらさんも落語がわかるようになったという話しをされていた。この話しはストレッチのトレーナーさんとも盛り上がった。

子どもだともっている情報が少な過ぎて情報を理解できないのではないか？

情報や知識を蓄積することで対象への解像度があがるにつれて、みる視点が変わったり、興味が変わったりすることはあるかもしれないなと聞いていて思えた。課題管理の話しをしても、多くの開発者は無関心だったり共感を得られなかったりするが、そこにも通じるものがあるのかもしれないとなにかしらの取っ掛かりになるかもしれないと思えた。

昨日は夕方に一度帰ってきて疲れてうたた寝して21時過ぎに晩ご飯を食べてそのままだらだらしてた。ドラクエタクトやりながら本を読みつつたぶん0時頃に寝て7時に起きた。

相続の手続き

先日 弁護士さんと打ち合わせ した書類の正式版ができた。関係者が同意しないといけない。次の3つの書類が必要になる。この書類作成と委任作業で弁護士さんは遺産の 1.1% を報酬として受け取る。成年後見人を要すると財産が弁護士さんに接収される気分になる。

• 民事委任契約書
• 遺産分割協議書
• 委任状

これらに相続権をもつ関係者 (母・姉・私) が署名、実印押印して印鑑証明を添付する。今日はそのために朝から実家へ帰ってきた。往路の途中で スターバックスのドーナツ を3種3個ずつ購入した。本当はケーキにしようと思ったのだけど、保冷剤がないというので暖かいから諦めた。私はスターバックスのドーナツを食べたことがない。ミスドよりも高い価格帯になっているけれど、その分おいしいんやろか？姉は喜んでたのでおそらくおいしいのだろう。

往路で姉から書類を受け取って実家へ着いた。トラクターで田んぼを耕してほしいというのでそれから1時間半ほど耕して畝を作ってお昼になった。そこで母に署名、実印押印してもらった。生涯に2回しか発生しない手続きなので直接行ってやり取りするぐらいの手間暇をかけてもよいだろうという所感。葬儀の当初から姉は相続に懸念を示していてすんなり押印してくれないかとも思ったけど、もう書類まで出来上がったので諦めて相続する気になったみたい。とくに揉めることなく同意してくれた。

ついでに離れのスペースをオフィスにするための備品を運んだり設置されたばかりのエアコンもみてきた。エアコンさえあれば夏でも作業できるし泊まることもできる。あと足りないものは机と椅子。コワーキングスペースのようにするなら大きなテーブルを購入してもよいかもしれない。

布施畑 JCT 経由の迂回路

15時過ぎには神戸に戻ってきた。車があるとほんと便利。朝から実家へ帰って田んぼして戻ってきてもまだ夕方前だった。今日は 第５０回神戸まつり なので住んでいる地域がお祭りをしていた。高速道路も混雑していたと思うし、時間もあったので 垂水 JCT を抜けて布施畑 JCT 経由の迂回路 を使って帰ってきた。距離的には少し遠回りになるけれど、マイナーなルートだけに車が少ないので速く走れるために時間的にはほとんど変わらない。

どこの分岐の違いでルートが変わるかを実際に走って覚えた。明石大橋を渡ってすぐのトンネルを抜けた後で左折すると垂水 JCT から名谷 JCT の通常のルート、直進すると布施畑 JCT のルートになる。明石大橋を渡っているときに高速道路の渋滞情報を聞いてどちらのルートを選択するかを判断すればよい。

0時に寝て何度か起きて7時に起きた。22時頃に素麺を食べたら夜に吐き気がして食べるんじゃなかった。

ストレッチ

今週はいつも通りの普通の1週間を過ごした感じ。休養していたわけでもなく負荷が高かったわけでもない。私の感覚的には右太もも後ろの筋と右腰の張りが強かった。トレーナーさん的には腰は大丈夫そうに言っていて、股関節全体の硬さは常態化しているものだけど、すねの筋もやや張りがあったように話していた。私の感覚とトレーナーさんの感覚がちょっとズレていた。今日の開脚幅は開始前154cmで、ストレッチ後158cmだった。一時期の3-4月の疲弊した状態ではないので一番悪い時期は脱したようにもみえる。

go の学び直し

Gopher塾 #5 - ジェネリクスが書けるようになろう に参加した。

すでにうちのプロダクトはジェネリクスを使った開発を行ってはいるけれど、私自身まだ曖昧なところがあったり、どういった設計がよいのかの手探り状態である。go はオブジェクト指向言語ではない (それ自体は構わない) ところが java のジェネリクスとは異なっていて、なにがその根本的な違いになっているのかを、私の中ではまだ理解できていなかった。その答えがこの勉強会に出てわかった気がする。もう少し独学して理論的に理解する必要はあるが、私に足りなかった知識が参加前よりも明確になったのでこの後の学習は容易に思える。

イベントではワークシートに自分で理解したメモや課題の回答を書き出すよう tenntenn さんが促していた。私はメモを自社の課題管理システムに書いていたのでワークシートには書いていないが、自分の理解を書き出すことの重要性は同意できる。tenntenn さんは次のように説明していた。

概念や理解したことを自分の言葉で表現できるか？を確認するために書くことは大事。

もし書いた内容が間違っていても、間違ったことを認識できることにも意味がある。

つまり、学んだことを書くことは正しくても間違っていても得られるものがある。

この考え方は私が提唱する課題管理にも通じている。なぜ書くかの理由の1つは自分の理解を整理するためでもある。そして、その文章を外部から監視できることで上長が助言できる。私にとっては習慣として身に付いた事柄ではあるけれど、改めてこういうことをチームのメンバーに啓蒙したり、開発ガイドに書いておくとよいように思えた。go の勉強会に参加して課題管理で学ぶことがあるとは思わなかった。よいこと尽くめだ。

閑話休題。本題のジェネリクスについて3割ぐらい知らないことがあった。私が java のジェネリクスと比べて go のジェネリクスを完全に理解できていなかったところの要因は 型の集合 (Type sets) の概念を理解できていなかったところに起因する。go ではジェネリクスを導入するにあたってインターフェースに型の集合という概念を導入した。それまでのインターフェースはメソッドの集合を管理するだけだったが、型の集合も管理できるようになった。また go には Underlying types という概念が当初から存在したが、それを意識してプログラミングすることはなかった。これを日本語にすると「基底型」となるが、オブジェクト指向言語で言うところの基底型とはまったく異なる。なにせ継承できないのだから。インターフェースに型の集合として次の記述ができるようになった。Underlying types はこれまで概念としてしか存在していなかったのがチルダを用いた文法で表現できるようになったため、その理解も強いられるようになった。

Go の “Type Sets” proposal を読む によると、現時点での型の集合とは次の2つを指す。

• ~T approximation element (近似要素)
• T | U union element (合併要素)

union 型のようなものは他言語でもある概念なのでイメージしやすいが、Underlying types をチルダを使って指定するのは go 独自？の概念なので新たに学び直す必要がある。

1時に寝て何度か起きて7時に起きた。23時に帰ってきて一昨日にお土産にもらったロールケーキだけ食べてしまった。あかんねんけど、おいしかった。

ドッグフードテストと運用談義

リリースしたばかりのプロダクトを社内に導入するべくインフラ作業をしている。社内の管理者が運用を考慮していくつか質問がくる中で、開発側としても運用の考慮の足りないところがあったりして、実運用における不測の自体に対する運用を想定しておく必要がある。こういうやり取り自体が、開発者だけでは得られない知見なので貴重と言える。追加の検証をして、場合によってはなんらかの機能を作ったりする可能性もある。

ドッグフードテストは本当によく出来た仕組みだと思っていて、仮になにか大きな障害が発生してもそれはお客さんのところで発生する前に自社でみつけられればよかったと考えられる。もちろん障害がなければそれはそれで構わない。障害が発生してもしなくてもどちらも開発にとって大きな資産となる。いわゆる win-win のような関係と言える。開発視点から言えばドッグフードテストを行うと決めた時点でうちらはすでに勝っていると言えよう。

プロダクト説明会

毎週やっているチーム勉強会の時間を使って社内向けにプロダクトの説明会を行った。リリースを終えて、その後のドキュメント作りやパッケージングの最適化なども行えた。インフラは十分に機能しているし、ドキュメントも一通り揃っていて、機能はまだまだ足りないけれど、プロダクトとしての体裁はうまくまとまっていると自画自賛している。リソースをかけた分だけスケールするといった開発体制に変化しつつある。おそらく私がマネージャーとして必要なのもあと3-6ヶ月といったところではないか？重要なことは 開発方法論/開発ガイド に書いてあるし、課題管理 + イテレーション開発は特別なことをしなくてもうまくいくことも立証された。メンバーが私と同じように振る舞えば誰でもマネジメントはできるはずである。

来週からは次開発のマイルストーンに入っていく。メンバーが成長して私のマネジメント工数が減るようになってくれば、私も開発に入って下支えすればいいと考えている。まずは3ヶ月でどのぐらいの追加の機能開発が出来ていくのかを見定めたい。

開発合宿の日程確定

そろそろ宿を予約しないといけない。冬の開発合宿 の予定を2024年3月1-3日に決めた。現時点で参加者は4名確定していて、前向きに検討してくれている人が3名いる。昨年が4名だったので倍増して今年は8名程で行ければいいなと希望をもっている。不特定多数に声をかけられるほどキャパシティはないけど、もう3人ぐらい声をかけてもよさそう。

1時に寝てやや吐き気で起きて休憩して3時ぐらいに寝たか寝てないかわからないうちに8時に起きた。ジンをたくさん飲んで帰ってきたのでうまく眠れなかった。

カスタム overlay モジュールの改修

OpenLDAP Overlays という機能がある。以前 ppolicy_hash_cleartext と カスタム overlay モジュール を組み合わせると ppolicy が平文パスワードをハッシュ化してしまって、自分たちのカスタム overlay モジュールから平文パスワードを取得できないことをデバッグで検証した。ppolicy_hash_cleartext の機能が必要なのかどうかが私はよくわかっていないけど、協調して自分たちのカスタム overlay モジュールが動くならそれに越したことはない。

gdb でデバッグして振る舞いと対応方法が分かったところで issue を作成していた。メンバーが暇だったらやってくれるかな？と思っていたら誰も手をつけないみたいなので私がやろうと決めた。最早、私は c 言語をなんも分からんのやけど、chatgpt に質問しながら教えてもらえる。例えば、c 言語についてもこんな感じにヒアリングしながら実装する。

Q. c 言語で関数の最初に変数を宣言するのと、実際に変数を割り当てるところで宣言するのでなにか振る舞いが違ったりしますか？どちらの方がよいのでしょうか？

C言語は伝統的に変数のスコープとライフタイムを管理するために、ブロック（通常は関数または制御構造内）の先頭で変数を宣言するスタイルを採用してきました。しかし、C99標準以降では、変数はその使用が初めて必要となる場所で宣言できるようになりました。 これら2つのスタイルの違いは、主にスコープ、可読性、そしてある程度はパフォーマンスに関連しています。

スコープとライフタイム

関数の先頭で変数を宣言すると、その変数は関数全体で使用できます。これは必要に応じて変数を再利用できるという利点がありますが、一方でスコープが広くなりすぎて変数の使用を追跡しにくくなるという欠点もあります。 一方、変数を使用が必要となる場所で宣言すると、その変数のスコープとライフタイムはその場所からブロックの終わりまでに制限されます。これは、変数の使用をより明確にし、未使用の変数を避けるという利点があります。

可読性

変数を使用が必要となる場所で宣言すると、その変数の目的と使用方法がより明確になるため、コードの可読性が向上することが多いです。一方で、関数の先頭で変数を一括して宣言すると、変数の目的が明確でない場合や、それらがどのように使用されるのかを追跡するのが難しくなることがあります。

パフォーマンス

パフォーマンスについては、現代のコンパイラは非常に高度に最適化されているため、変数の宣言場所がパフォーマンスに直接的な影響を及ぼすことはほとんどありません。

結論

どちらのスタイルを選ぶかは、主にプログラミングスタイルやチームのコーディング規約、または特定のタスクに対する特定の要件に依存します。しかし、変数を使用が初めて必要となる場所で宣言するスタイルは、コードの可読性を向上させ、変数のスコープとライフタイムを制限するという利点から、一般的には推奨されています。これにより、コードの可読性が向上し、変数の使用範囲が明確になるため、コードの理解と保守が容易になります。

そっか。C99 で変数宣言の制約が撤廃されたんだということを学んだ。そんな感じで openldap についても chatgpt にヒアリングしながら開発したら意外とすんなり実装できてローカルでは動いた。レビューまでできた。

遅く帰ってきたわけではないが、うまく眠れなくて3時に寝て7時に起きた。

開発方法論／開発ガイドの更新

今週が開発の谷間の最後の週。毎週いろいろ資料を作ったり、あちこちのドキュメントを更新したりしていた。最後に残ったものの1つ (を2つに分割した) として、うちのプロダクト開発における開発方法論と開発ガイドを仕上げた。開発方法論は開発のマネジメント手法やプロセスの概念などを抽象的な表現で説明したもの。簡単に言えば、アジャイル開発とかスクラムとか、そういった概念の説明やなぜそれが大事なのかの意図や背景を説明したドキュメントになる。当初はこの1つしかなかったのだけど、実際に課題管理システムを使ってイテレーション開発をする具体的な話しと抽象的な話しを一緒に書くのはまとまりが悪いように思えてきた。抽象的な内容と実務に近い内容は分けて書くことにした。

• 開発方法論: プロダクトで採用している開発方法論の概念をまとめる
• 開発ガイド: 開発方法論を具体的に実践する方法についてまとめる

例えば、開発ガイドにはマージリクエストの運用について書いてある。どこの会社へ行っても私は次のような「マージリクエストを作成しなくてよいもの」という文章を書いている。

すべての修正にマージリクエストを要求すると開発がとても遅くなる。それは人間が介在するトコロがもっともコストを要求するからである。とくにコミュニケーションコストは開発の中でも最も大きいコストの1つである。レビューしなくてもコミット履歴は誰でも把握できる。修正内容が気になる開発者は自分でコミット履歴を確認すればよい。

従ってレビューの必要がないと想定される修正は直接 main ブランチに push してよい。例えば、軽微な修正は CI/CD の自動化により品質を担保できるように努める。テストを失敗させる修正を push してしまったとしてもデプロイできないために障害を発生させることはない。

この運用は軽微な修正だと思って push したものが不具合を発生させてしまうリスクを許容している。そのときは気付きの学びとして「ごめんなさい」で終わらせる。稀に不具合を発生させることよりも、開発の速度を上げる方を優先する。

カフーツさんイベント

カフーツ13周年Jelly〜カクサク（やりたいこと宣言）第1弾〜 に参加した。私がカフーツさんへ遊びに行ったときに人がたくさんいたことはない。記念イベントだったので参加者多いかな？と思って行ってみた。10人ぐらいいた。参加者の大半は私と同じぐらいか、それ以上の年配の方にみえた。やや年齢層が高め。13年やっているコミュニティなので同じぐらい歳をとったんだと思う。みんなでわいわい話しながら0時前まで飲んでた。ここ行くと基本飲み会w

YOHAKHU というクラフトジンがあってロックと炭酸割りで4-5杯ほど飲んでいた。これまでジンをあまり飲んだことがないので、普通のジンとの比較はできないが、強烈なインパクトのある風味で圧倒されてしまった。おいしいかどうかというよりもこれは強烈やなぁという所感が先にくる。さらに「余白」という名前がよい。いとうさんに影響を受けて私が「ゆとり」と呼んでいた概念にいくつか補強がされて、最近は私も余白という言葉を気に入って使っている。人生に必要な余白を忘れない飲みものがこれだと言えるかもしれない。なんだか酔っ払ったようなコメントになってしまった。

0時に寝て何度か起きて6時に起きて7時半に起きた。最近疲れからか6時ぐらいに2度寝してしまうことが多い。

定例会議

先週の東京出張で次開発の打ち合わせをしてきたので、今日はそこでいくつか絞り込んだものから決議を行った。すんなりと次の開発課題が決まって時間に余裕があったので、別の曖昧な要件の認識合わせもしていた。半年やって私自身のシステムへの理解やドメイン知識も付いてきたところではあるが、この要件の認識合わせが現状の範囲で私の理解が追いついていないところの最後のピースにもみえる。この要件の背景と解決方法の設計を論理的にやってしまえば、あとは課題管理に馴染んできたうちのメンバーがうまく開発してくれるのではないかと思う。

半年間の開発、課題管理とイテレーション開発のプラクティス、リリースできたという結果、そして主体変容を示唆して過去の自分と比べてどう変わったかをふりかえりで確認した。なんとなくメンバーの働き方が変わってきた感じがして頼もしくなってきた。少なくとも半年前より私が言っていることの意味や価値を理解して開発に取り組んでくれているのではないかと思う。次の開発がどのように展開していくのか、楽しみになってきた。今週はドッグフードテストのインフラ作業をメインにして来週の水曜日から次開発に入ることにした。

車でお買いもの

少し早めに帰ったので車で近所のスーパーへ買いものに行ってきた。過去の記録をみると1月29日に満タンで給油した。そのガソリンがまだ半分ぐらいある。うちの車は燃費のよいハイブリッドカーだ。いくつかの記事をみるとガソリンの消費期限は3-6ヶ月程度だと書いてある。目安としては3ヶ月程度で消費するのが望ましい。長くて6ヶ月程度にしないとエンジンや燃料系の故障の原因となりえるらしい。気温の変化が大きいとさらに劣化が早まるとかあるそうだ。平時はガソリン満タンじゃなくて少しずつ給油した方がよいことに気付いた。

4時過ぎに寝て7時に起きた。3時前まで相続手続きの書類作業して帰ってきてから本を読んでたら寝るのが遅くなった。

メンバーの oss へのコントリビュート

チームのメンバーがプロダクトで使っているライブラリにコントリビュートした。土日にライブラリのメンテナーからコメントがあって、その指摘にもすぐに対応して日曜日にマージされていた。ライブラリ側のレビューもすぐに終わってすごくうまくいったと言える。

• feat: enable DirSync control in search operation #436

もともとうちらが欲しい機能を作りかけた pr があったものの、作業途中でマージされずにクローズされていた。その残骸を参考にうちらの要件を満たせるかどうかの調査から始めた。調査を進めているうちにうちらの要件には足りない機能があってそれを拡張するようにも指示していた。すぐに出来たというのでライブラリにコントリビュートするように私が指示していた。

その後メンバーに聞いてみると、oss のライブラリにコントリビュートしたのは今回が初めてだという。開発者なら初めて oss にコントリビュートしたときのことを覚えているだろうか？私は、、、何だったか覚えてないが、おそらく linux distributor で働いているときに簡単なパッチを送った気がする。昔はメールや課題管理システムにパッチを投稿していたのが、いまは pr で気軽にパッチを送れる。若いメンバーがうまくコントリビュート経験を積めたことの背景に github がもたらしたパッチを送る簡単さがあるようにも思えた。oss にコントリビュートする機会は普通に oss を使って開発していればいくらでもある。マネージャーがその機会を見逃さず、ちゃんとメンバーにアサインしてあげることの大事さもあると思う。メンバーにはこの成功体験を活かして今後とも活躍してほしい。

サイトデザイン打ち合わせ

先日の ワイヤーフレームのレビュー の続き。顧問のはらさんとデザイナーさんと私の3人でデザイン案をみながらレビュー会をした。素人の私からみたら十分によいものが出来つつあるように思えるのでデザイナーさんのモチベーションを削がないようにサポートできればと思う。はらさんはデザインの専門家なので細かいところの確認や気付きをあげていてさすがという印象。きっとデザイナーさんのモチベーションも上がるのではないかと推測する。私はこれまでデザインの打ち合わせに出たことがなかったので参考になることが多々ある。サイトのトップは普通は会社の紹介があるものらしいけど、私がそれはいらないとデザイナーさんに伝えたのでトップで会社紹介を一切しない稀な構成のサイトのデザインが出来上がった。その後、社名ぐらいあった方がよいのではないかという話しもあってこれから変えるかもしれない。私の会社情報を書かない理由は次になる。

• 一見さんの訪問客がみるようなサイト (会社) ではない
• 知人やうちの会社の関係者がみて近況を手早く分かるようにしたい
• デザインはシンプルな構成にしたい

2時に寝て遅くまで飲んでいたせいか、やや吐き気もしながら朝起きてだらだらして11時ぐらいに起きた。

1password のロック解除を yubikey で行う

先日購入して触っていた yubikey bio の設定 の続き。1password のロック解除を指紋認証で行いたかったが、1password の 8.10.4 のアプリではロック解除をシステム認証で行おうとするとエラーが発生していた (バグってた) 。5月の頭に 8.10.6 がリリースされていてシステム認証のバグが直っていることに気付いた。1password のアプリケーションがどうやって linux のシステム認証を使っているかは次の1文に書いてある。

システム認証は、Linux のユーザーアカウントに組み込まれたアクセス制御機構を使用します。これは polkit と PAM (Pluggable Authentication Modules) という2つの Linux 標準に依存しています。この2つを組み合わせることで、安全な認証サービスを提供します

https://support.1password.com/system-authentication-linux/#about-system-authentication-security

私は polkit を使ったことがなくて初見でよく分かっていないが、どうやら polkit から pam を介して認証しているようにみえる。pam.d 配下の設定を調べてみると /etc/pam.d/polkit-1 がある。前回の設定で pam.d の設定とテストの方法を理解していた。ここまでくれば Module Arguments のドキュメントをみながらオプションを設定するだけ。1Password のロック解除をYubiKeyでやる の記事で origin/appid にホスト名を指定しているが、最新のモジュールだと指定しないときはデフォルトでホスト名が使われるようにみえる。

• origin: FIDO 認証手順の party ID を設定する、値が指定されない場合は識別子 pam://$HOSTNAME が使用される
• appid: FIDO 認証手順の application ID を設定する、値を指定しない場合は origin で使用されたものと同じ値が使用される (origin も指定しない場合は pam://$HOSTNAME)
• nouserok: 認証しようとするユーザーが authfile 内に存在しない場合や authfile が欠落/不正確な場合でも、認証の試行を成功させるように設定する
• cue: タッチすることを促すメッセージを表示するように設定する

これらを踏まえて u2f で認証が成功したらそれ以降の処理をスキップするように次の設定を先頭に追加する。

$ sudo vi /etc/pam.d/polkit-1
auth   sufficient   pam_u2f.so nouserok cue
...

cue を指定したことでパスワードプロンプトを表示せず、デバイスをタッチするように促される。よい感じ。

$ pamtester polkit-1 t2y authenticate
Please touch the device.
pamtester: successfully authenticated

これで pam の polkit の設定が正しいことを検証できる。この後に 1password のアプリケーションでロック解除するときに u2f を使って指紋認証できた。めっちゃ便利。