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 にヒアリングしながら開発したら意外とすんなり実装できてローカルでは動いた。レビューまでできた。

昨日は久しぶりに飲みに行っきて1時に寝て8時に起きた。

ストレッチ

外がだいぶ暖かくなってきて散歩に行く機会も増えてきた気がする。今日の開脚幅は開始前157cmで、ストレッチ後159cmだった。先週と違って今週は忙しくて座っている時間が大幅に増えた。そして、その分の右腰の張りは強かった。腰の張り具合はその週の忙しさや労働時間で推測できるぐらいにはわかってきた。それ以外はだいたい可もなく不可もなくな感じだったと思う。

淡路牛の受け取り

姉からお肉が届くという連絡があったので日時を調整して受け取った。島サラダフェア2022 という懸賞に応募していたのが当たったらしい。5000円相当の淡路牛らしい。お正月に食べるようなお肉だと言えば伝わるかな。A賞の5名のうちの1人がここにいるので総応募数は推して知るべし。姉が言うには全然応募ないらしい。こういうの調べて真面目に応募してメルカリで売るみたいなことやったらそれなりに儲かるのかもしれない。運営はマーケティングのやり方を変えた方がいいんじゃないかとか心配になって話していた。

openldap の overlay のデバッグ

午後から昨日の続き。chatgpt と一緒に openldap サーバーのカスタム overlay モジュールのデバッグをしていた。昨日の時点では2つの問題があることを確認できていた。今日は個々の問題の詳細をデバッグしながらワークアラウンドとして動かすためのコードを書いた。1つはビルドの問題じゃないかと思える不可思議な現象が起きていて、もう1つは openldap の ppolicy の仕様とカスタム overlay モジュールの仕様のどちらが正しいのかを設計者に確認する必要がある。15年ぶりぐらいに c 言語のコードを書いている。かなり怪しいけど、gdb をインタラクティブな repl のようにして振る舞いを確認しながら書いている。カスタム overlay モジュールでエラーが発生すると openldap はその処理をスキップするようにみえて、なんのログも出ない。細かくログ出力してどこまで動いたのかを確認しながら開発するとよさそうな雰囲気がわかった。

2時に寝て6時半に起きた。開発の追い込みが佳境に入ってきて集中力が増してきた。

chatgpt と一緒にデバッグ

openldap サーバーの拡張の仕組みに Overlays がある。c 言語でカスタム overlay を実装することで openldap サーバーに任意のフック処理を実装できる。いまやっていることはパスワードの追加や更新をフックしてそのパスワードを id 連携するためのモジュールを開発している。というか、開発済みだと聞いていたモジュールが意図したように動かないのでデバッグしている。例えば ppolicy という overlay を使って次のように設定すると、平文で送ったパスワードをディレクトリサービスの db へ格納する前に平文からパスワードをハッシュ化してくれる。この変換はパスワード変更を overlay でフックして実装されている。

overlay ppolicy
ppolicy_hash_cleartext on

overlay は slapd.conf に設定した順番に実行されるようで、それぞれの overlay に依存関係がある場合は実際の処理にも影響がある。そんな openldap サーバーの拡張モジュールの開発を引き継ぐことになったが、私がまったく openldap サーバーのことをわかっていないので chatgpt を使って理解しながらデバッグしている。これがそれなりにうまくいっていて調査が捗った。但し、chatgpt が教えてくれたことなので完全に正しいかどうかの保証がない。振る舞いで検証できるものはともかく、そうじゃないものは最後に有識者に正しいかどうかを確認する必要がある。

例えば、次のような ldif エントリーをサンプルとして、パスワードは userPassword という属性で扱う。ここで userPassword だけコロンが2重 (::) になっていることがわかる。これは属性の値が base64 でエンコーディングされていることを意味している。こういった2重コロンのような短いキーワードを検索で調べるのは難しい。chatgpt ならピンポイントに答えてくれる。

dn: uid=jdoe,ou=users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: jdoe
cn: John Doe
givenName: John
sn: Doe
mail: jdoe@example.com
userPassword:: e1NTSEF9bm9ZMU5kdzN3WUdSbFhpdDJUaTY5UW9SeXpXaklEeXc=

openldap は oss だし、ドキュメントもインターネット上にあるので構造体の定義や c 言語のサンプルコードも書いてくれる。それらが完全に正しいか、私には判断できないが、openldap のソースコードで調査するところの当たりをつけるには十分な情報を返してくれる。カスタム overlay を開発するときの主要なエントリーポイントと ldap 操作のタグ名は次になる。

• bi_op_bind: バインド（認証）操作に対応するエントリーポイント、LDAP_REQ_BIND
• bi_op_search: 検索操作に対応するエントリーポイント、LDAP_REQ_SEARCH
• bi_op_compare: 比較操作に対応するエントリーポイント、LDAP_REQ_COMPARE
• bi_op_modify: 修正（属性の追加、削除、変更）操作に対応するエントリーポイント、LDAP_REQ_MODIFY
• bi_op_modrdn: エントリ名の変更 (MODIFY RDN) 操作に対応するエントリーポイント、LDAP_REQ_MODRDN
• bi_op_add: エントリの追加操作に対応するエントリーポイント、LDAP_REQ_ADD
• bi_op_delete: エントリの削除操作に対応するエントリーポイント、LDAP_REQ_DELETE
• bi_op_abandon: 中止操作に対応するエントリーポイント、LDAP_REQ_ABANDON
• bi_op_extended: 拡張操作に対応するエントリーポイント、LDAP_REQ_EXTENDED

例えば、LDAP_REQ_ADD は ldap.h で次のように定義されている。

#define LDAP_REQ_ADD        ((ber_tag_t) 0x68U) /* application + constructed */

これを gdb でデバッグしてタグを確認するときは次のように Operation 構造体内の o_tag をチェックすればよい。gdb で16進数表示するときは /x を指定する。

(gdb) print /x op->o_tag
$8 = 0x68

ppolicy よりも前にカスタム overlay を設定すれば平文のパスワードにアクセスできそうにみえるのだけど、gdb でデバッグしているとハッシュ化済みのパスワードになっていた。

あと稼働している openldap サーバーに gdb で attach してデバッグする方法も chatgpt に聞きながら行った。やりたい操作に対して gdb のコマンドを教えてもらってすぐに検証してフィードバックからさらに質問できるのでインタラクティブな repl のような環境と chatgpt は相性がよいように思えた。gdb のコマンドを覚えておく必要も、ググる必要もないことに気付いた。

近況報告

元同僚と 約1年ぶりの近況報告 の雑談会をしてきた。これで3回目かな。毎年の恒例行事のようになってきた。兵庫県の住みたい街ランキングでいつも上位にある 西宮市 でカレーを食べて、バーで飲んできた。三ノ宮から西宮は快速で15分程度の距離。すぐ行ける場所なんだが、とくに行く機会がなかったので神戸に引っ越してきて5年以上経つのに電車で行ったのは今回が初めてになる。いつも通り近況を聞きながら、みんな私と同じぐらいの世代なので今後のキャリアの方向性などを話していた。

私は起業して税金やその仕組みに関心をもつようになり、起業する前より少し詳しくなった。知人から節税相談を受けることもある。税金の基本的な考え方として、1つの大きな収入に対して節税することはできない。自由に使えるお金がほしかったら基本的に節税できない。税金をたくさん払って貯金するしかない。一方で個人と会社に資産を分割したり、共済や基金を活用することで手取りの収入は減るが、支払う税金は少なくなって中長期でみると資産が増える。例えば、共済や基金に積み立てたお金は原則としては退職所得で戻ってくるので、ずっと優遇された 退職所得の所得税 により、最終的に支払う税金が少なくなるからである。これが税金を支払う基本的な考え方。自分の手元にお金を残した上で税金を払いたくないが、どうすればよいか？とよく聞かれるが、そんなことはできないというのが模範回答になる。元同僚も私もそうなのだが、もはや自分の生活にお金をあまり必要としていない。私が節税の仕組みを調べたり実践したりするのは、税金の仕組みを学ぶために過ぎない。ただ知識として学ぶよりも、実際に実践して運用してみる方が学びになる。

以前の 出張もくもく会 の後で懇親会のときにそのうち資本主義は新しい制度にとって変わられるのではないかという話題があった。それは行き過ぎた資本主義の弊害と、資本主義である限り40時間/週の労働時間から抜け出すには資本家になるしかなくて、人類はすでにこれだけ技術があるのだからもっと多くの人が今よりも働かずに食べていけるのではないかと多くの人が考えている。私の場合も、実質は自分のやりたいことしかやってなくて、自分のために働きながらも、老後のために一応はお金をもらっておくみたいな働き方になっている。この考え方は資本主義の次の制度へ移行するときに活きてくればいいなと思う。

23時に寝て2時半に起きて4時や5時に起きて7時に起きた。泊まっているホテルの低反発枕の寝心地がよい。

rsync daemon over ssh

外部向けのドキュメントを公開するための gitlab ci/cd を構築した。web サーバにドキュメントをアップロードする手段として rsync を使っている。rsync over ssh でデータを転送するときにさらに daemon モード (rsyncd) という仕組みがあって、権限や書き込み先の acl なども細かく制御できる。手順や設定は古の古臭い雰囲気はするけれど、実用的には ssh の秘密鍵を使ってちょっと高機能なアップロードを実現できる。ssh agent で鍵登録できていれば次のような cli でセキュアに rsync できる。全然知らない方法だったので学びの1つになった。

$ rsync \
    --verbose \
    --rsh ssh \
    --stats \
    --compress-choice=zstd \
    --compress-level=10 \
    --itemize-changes \
    --recursive \
    --checksum \
    --delete \
    local/ ${USER}@${HOST}::${RSYNC_DIR}

• rsync+sshはdaemonモードを使うと更に安全になる

LLMを使ってみる会

LLMを使ってみる会 に参加した。私も chatgpt に調べものやちょっとしたことを聞くようになったりしているが、他の人たちがどんな用途に使っているのかも知りたくて参加してみた。fin-py のイベントだったのでみんな金融系のドキュメントの要約に使っているのが多そうにみえた。あとは研究テーマとして gpt/llm を取り上げている人たちも何人かいた。

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

隔週の雑談

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

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

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

社員数を調べるハック

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

chatgpt 勉強会

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

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

1時に寝て8時に起きた。昨日は久しぶりに飲みに行ってきてよい気分で寝た。

ストレッチ

今日の開脚幅は開始前154cmで、ストレッチ後158cmだった。すねの外側の筋は大分よくなって通常の状態に近くなってきたと思う。今日の張りが強かったところは右股関節の内側と右腰になる。これまでもずっとよくない部分ではあるが、いつも体調に戻ってきたという見方もできる。あと右のお尻の後ろの筋もやや張りが強い気がした。2月中旬から納期に間に合わせるためにいくつかズルをしてきたところの埋め合わせというか、体調管理をこれから少しずつやっていく。結果的にその方が日々の活動のパフォーマンスが高くなる気がする。

gpt-4 談義

タイムラインをみていると GPT-4 がすごいという投稿が散見されるので課金して使ってみることにした。$20/月なので十分に安いと思う。会社のお金を自由にできると、技術調査や業務に関することの決済を即決できる。これは経験を積んでお金をかけるところとそうではないところに一家言もつようになってくるとそのストレスの度合いも違ってくる。まだ使い始めたばかりなので技術調査をするときにググる代わりに gpt-4 に尋ねて回答を確認するといった使い方しかしていない。具体的に言うとどう使ったらいいのかわからないので誰でもやる使い方から慣れていって、そのうちにもっと幅広い応用に気付くようになったらいい。

タイムラインをみてもどう使ったらいいかをあーだこーだと議論しているようにみえる。次の資料をみていて、対話形式というのは人間の質問や誤りの指摘をアノテーションとして gpt-4 はより正しい言葉選びをしているとある。ドメイン知識がある人が品質の高いアウトプットを得られるというのは、アノテーションを正しく gpt-4 に与えてあげないといけないという理屈で理解できた。

• ChatGPT と自然言語処理 / 言語の意味の計算と最適輸送

アノテーションの与え方が従来の検索のように lang=go のように構造化されたパラメーター指定ではなく、自然言語のまま非構造化データで与えられるというのが、従来の検索よりも進化したとも受け取れる。一方で gpt-4 に質問して文章を生成するのに1-2分かかるのでその待ち時間は検索よりも体験が悪い。私が大学のときはインターネット検索というのが普及し始めた時期だったから「どうやってその情報をみつけたの？」「検索するときにコツがあるんですよ」みたいな会話がよく聞かれた。いま gpt-4 を使っていて、その時代と同じような既視感を覚える。