Posts for: #Ldap

よく働きよく動く

#ldap  #design  #health  #exercise 

今日の運動は腕立て,スクワット,縄跳び(両足跳),散歩をした。統計を 運動の記録 にまとめる。

ou エントリーの更新対応

ここ2週間ほどずっと、お仕事のある機能開発で テンパった開発状況 でやってきたものがようやく終わった。私は自社の経営だったり、プロジェクトのマネージャーだったりで、普通の開発メンバーのような集中した開発を時間的にできないものの、それでも私が1つの機能に2週間もかける開発はそうそうない。想定以上にこの対応のために、扱う LDAP エントリーのデータ定義や既存システムの実装変更を余儀なくされた。逆に言えば、既存の実装にそういった考慮が当初の設計に足りなかったと言える。この改修において ID 連携におけるノウハウをメンバーと共有したとも言える。

運用視点からは出来て当然の、しかし、開発視点からは厄介な仕様変更の開発を完了できた。いまの時点では完璧に作ったので将来的な拡張も含めて、さまざまな要件に対応できる設計になったと思う。自画自賛だが、時間をかけた分のよいものができたと思う。

みなとのもりの運動

今週の前半は雨降りだったり、雨が断続的に降ったりやんだりでお出掛けできなかった。お仕事も一区切りついた開放感と久しぶりによい天気だったのもあって みなとのもり公園 へ行って縄跳びしてきた。運動できない日々が続いて体力を回復していたせいか、15分間のワークアウトで過去最高の 1113 回となった。前回よりも大きく回数が増えたので、もしかしたら100ほど計測ミスがあるのかもしれない。いまの目標としては15分間で最低800回跳ぶことを想定している。跳んでいるうちにカラダが慣れてきて、ミスしなくなったり、フロー状態に入って速く巧く跳べて回数が増えたりする。

縄跳びの前後にストレッチをできるよう、大きめのレジャーシートも買った。100円ショップなどで売っているレジャーシートに比べたら少し厚手になる。折り畳んで持ち運びできるのがいいなと思って購入した。公園へ持っていくのに便利。1人なら完全に寝転がって広々とストレッチできる。よいと思う。

4月1日の月曜日

#go  #ldap  #project management  #issue management  #team building 

23時頃に寝て4時に起きて6時に起きた。変な寝方した。私はわりと月曜日は好き。休み明けで元気だから、世の中的には逆かもしれないが。月曜日に加えて、今日は4月1日で新年度とあってさらに新鮮な気持ちになって晴れ晴れしい。

今日の運動は腹筋ローラー,腕立て,縄跳び(両足跳)をした。統計を 運動の記録 にまとめる。

go-ldap のコントリビュート

過去に私がコントリビュートした非同期検索の機能のなかで context によるキャンセルと channel の操作のところで効率のよい方法を提案してくれた方がいた。私が開発していて気付かなかったところをリファクタリングした。指摘されればその通りだと思う。開発していて non-blocking な select 文を書くことに気を取られているとその認識が漏れていたといった程度のリファクタリングになる。ちょうどいま go-ldap ライブラリを使うアプリケーションのデバッグをやっていて、特定のケースにおいてブロックしてしまう現象に遭遇していて、この context と channel の select 文の扱いが参考になった。issue をあげてくれた方に感謝。

アウトプットがない開発者への対応

お手伝い先でフルタイムの新規開発者が1ヶ月たっても機能開発の issue を1つも fix できていない。svelte で新規の一覧画面を作ってもらう、相対的に簡単な issue なのだけども1ヶ月かけてマージリクエストを出せるレベルにはなっていない。そして今日は休暇をとっている。普通の開発者の感覚として、どんな理由があろうと1ヶ月で issue を1つも fix できていない状況は異常だと思う。ほかメンバーだとそれぞれ16と8つの issue を fix している。もちろん開発者によってやっていることや取り組んでいることの複雑さが異なるため、単純に数が多ければよいというわけでもない。そして内容については私が課題管理を介して把握しているので他のメンバーの働き方になんの問題もない。どんな issue に取り組んでいても1週間に1つも fix できないという状況にはなっていない。1ヶ月かけて開発の issue を1つも fix できないというのがどれだけ異常な状況かはわかると思う。明日から出張で経営陣と進捗について話すときに大きな問題の1つとして共有して対策を検討する必要がある。

致命的バグをみつけた

#ldap  #debug  #design  #tax 

2時頃に寝て5時過ぎに起きた。お風呂に入るときに fitbit を外して、その後付けるの忘れて寝てしまったから睡眠時間を計測できなかった。

今日の運動はレッグレイズ(椅子),腹筋ローラー,腕立て,スクワットをした。統計を 運動の記録 にまとめる。

agent の致命的なバグ

先週から QA テストをしていて agent の致命的なバグに気付いた。もともとあった java 製の agent から私が設計して作り直した go 製の agent になる。ldap エントリーの更新リクエストのテストツール を作ったことでシビアなタイミングによるバグを検出できた。

ツールを使ってテストしていて、成功するはずのリクエストが失敗して、ログを調査しながらデバッグしていた。ldap エントリーを扱う難しさの1つに、ldap サーバーはエントリー間の依存関係やデータの整合性といったものを検証しない。そういった用途はアプリケーションの役割であって、ldap プロトコルはあくまで id を管理することに特化したものという役割分担になっているのだと推測する。そうすると、(open) ldap サーバーへ登録できたエントリーが次の agent や api サーバーといったアプリケーションのレイヤーでエラーになることがある。このとき、ldap サーバーではエラーが発生していないため、直接的なエラーを検知することができなくて、デバッグや調査に時間がかかる。

agent の実装として、ユーザーエントリのストリームとグループエントリーのストリームの2つに分割して、非同期にそれぞれのエントリーを id 連携する設計にしていた。というのは、ldap エントリーにはユーザーやグループといった概念は原則として存在しない。そのエントリーがユーザーなのか、グループなのかはアプリケーションが判断している。アプリケーションの用途としてはこの2つを明確にわけないと不便なことから、ワークアラウンドもしくは実務的な解決策として検索するときのフィルターと base dn で管理するようにしていた。そして、これらをそれぞれ別のストリームとして扱うよう、私が設計していた。このことがタイミングによってはユーザーエントリーとグループエントリーに依存関係がある場合、データの整合性を保証できないことに気付いた。なぜならば、ユーザーエントリーとグループエントリーそれぞれ非同期／並行に処理されてしまうから。

結論としては、ldap サーバーからエントリーの更新の順序を保証するには1つのストリームを subscribe しないといけない。そして、ストリームから取り出したエントリーがユーザーなのか、グループなのかはアプリケーションが判別しないといけない。テストツールを作ったことでシビアなバグも検出できた。

定額減税

定額減税 特設サイト が公開されたらしいというニュースをあちこちでみつける。従業員の税金が安くなるので経営者としての私がなにかしないといけないと思っているけれども、まだ何をしていいのかよくわかっていない。時間をみつけて調べないといけない。税制が変わるとこういった事務手続きが突発的に入ってくるのがマイクロ法人の面倒なところ。

ホットクックのレシピを upnote で書く

#founding  #recipe  #health  #upnote  #go  #ldap  #design 

2時半に寝て５時過ぎに起きた。それから二度寝して7時に起きた。

今日の運動はレッグレイズ(椅子),腹筋ローラー,腕立て,散歩をした。統計を 運動の記録 にまとめる。

トランクルームの契約

家電を購入すると大きな箱が付いてきて物理的にその置き場所がない。箱を捨てるという戦略もあるが、オリジナルの箱があると引っ越しや売買／処分するときに便利なのでできれば残しておきたい。これまでデスクトップマシンの箱やオフィス備え付けの椅子などをマンションの部屋に保管したりしていたけど、家電の箱が増えてくると邪魔になってきて、トランクルームを借りることにした。面倒なのであまり調べていないが、スペラボ というサービスの屋内型トランクルームをレンタルすることにした。0.7畳で6,450円/月(税込)になる。会社の経費だしこのぐらいの金額ならいいかと思って、朝から内見に行って問題なさそうなので即決した。

ホットクックレシピの公開

ホットクックのレシピをどこかに整理したい。スマホ上でも調理しながら簡単に確認したいとなると web よりもアプリの方がよい。そこで evernote から移行した upnote に書くことにした。実際に調理してみて、デスクトップマシンでレシピを編集・整理して、写真はスマホアプリからアップロードするといった使い方ができる。View shared notes によると、ノート単位で web 公開もできる。試しに次のレシピを公開してみた。ノートブック単位で公開設定して一覧ページがあるともっとよいが、その機能はないみたい。公開リンクを作成する一手間はあるけれど、そんなにレシピノートを書くわけでもないから気にはならない。

ホットクック調理は材料入れてボタン押したら終わりではないか？と思うかもしれない。いや、そうでもないようだ。たしかに材料を内鍋に入れてボタン押したら人間ができることは何もない。だからこそ、ボタンを押す前の過程が大事になってくる。どんな切り方をするのか、素材のサイズはどうか、初期配置はどうか。例えば、豚ロース肉の生姜焼き用を買ってきて、適当に切って3枚4枚重なった状態で投入したらそのままの状態で出来上がった。かき混ぜ棒があるからうまいこと豚肉もバラけるだろうと期待したが、ぴったりくっついているようなお肉をバラかすほどのパワーはないようだ。人間が最初からバラかした状態で内鍋に投入すると、出来上がりのときに豚肉のかたまりがなくなってよいと思う。

あと気付いたこととして、野菜もお肉も素材を少し小さめに切った方がおいしいように感じる。というのは、ホットクックは圧力鍋ほどの火力で調理しない。圧力鍋に慣れていると、少し大きめに切っても原形がなくなって溶けてしまったり、出来上がり時点で原形があっても混ぜたりしているうちに角がとれて、どんどん小さくなっていく。小さくならなくても口の中でとろけるので大きいままでも問題ない。相対的にホットクックはそこまでの火力はないから、小さめで味が染み込むような出来上がりになるため、小さめに切っても原形は保ったままで溶けてなくなってしまうことはない。これは良い悪いではなくて、それぞれの製品の特徴と言えるだろう。ホットクック調理は素材を小さめに切るというのが、いまところ、私が作ったレシピではうまくいっている。ホットクックでは、小さく切った複数の素材をほお張って食べるのがおいしい。

go-ldap への context 導入の考察

go-ldap の issue は subscribe しているので、たまたま initial cut of context support #406 の draft pr のコメントに気付いた。過去に context を導入しようとして途中で断念した残骸みたいな pr になっている。いまの go の api は context を受け取るのが当たり前になっているので確かにほしいというのは理解できる。

代わりに私がやってみようかとソースコードを読んでみた。オリジナルの draft pr は client の interface に WithContext なメソッドを追加しようというもの。go の context の扱いとしてもっとも基本的なもの。それでもよいけれど、net/http の実装はどうなっているのかを調べていたら Request 構造体のメンバーとして context を保持していることがわかった。このやり方は原則のルールに反するものだけど、context を状態として扱わず、限定的な用途にのみ使っている。これは既存の interface を変えずに context 導入をしようという意図があると推測する。この考え方でいくと、go-ldap の Request 構造体に context を保持するように変更する方が既存の API の変更を少なくして net/http の Request も同様にやっているからと説明もしやすいように思えた。

type Request struct {
...
	// ctx is either the client or server context. It should only
	// be modified via copying the whole Request using Clone or WithContext.
	// It is unexported to prevent people from using Context wrong
	// and mutating the contexts held by callers of the same request.
	ctx context.Context
...
}

今日のところは go-ldap と net/http のソースコードを読んで設計をしていた。また明日余裕があったらサンプル実装してみる。

ローカルに window server をインストールした

#ldap  #cli  #virtualization  #windows  #active directory  #event 

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.

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

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

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

生活リズムが崩れた月曜日

#animation  #economy  #go  #ldap  #hugo 

1時に寝て2時半に起きて5時に起きて7時に起きた。朝から昼過ぎまで寝てたのでトータルでは睡眠時間をたくさん取っているのになんか疲れている。生活のリズムを崩すのがよくないのかも。

ガンダムに学ぶ経営学

教えてもらって寝る前にみたらおもしろかった。入山先生がガンダム大好きなことが伝わってくる。おもしろいのはそうだけど、まじレスすると、アニメの世界の組織や経済に学ぶというのは誤りで、当時の組織や経済のリアルを参考にして、ガンダムの世界観は作られていると推測する。だから入山先生はユーモアで盛り上げているのだと思うけれど、ガンダムから学ぶのではなく歴史から学べが正解だと思う。でも、ガンダムの世界観を知るよい番組だと思う。

go-ldap へのプルリクエスト

2週間ほど前に送った pr がまだレビューすらしてもらえていない。github actions のテストがいくつか落ちていて、この pr の修正によるものではないところでエラーになっている。メンテナーの1人が再実行してくれたんだけど、たくさんあるマトリックステストのどこかが落ちてまた再実行しないといけない。

それを待っている間に、テストがエラーになる本当の原因の問題を直そうと2-3日前に issue 登録していた。この issue の対応を本当は昨日やろうと思っていたのに、思いの外、寝てしまって、その後もいろいろ書きものをしていて時間を使ってしまってできていなかった。今朝からそれを片付けた。業務の一環なので日曜日にプルリクエストを送らなくてもよいのだけど、コントリビューションなので空き時間に終わらせて、業務の時間は別のことに使いたいという思いもあったりする。

さらに github actions のログに deprecated ワーニングが出ていたのでついでにそれも直した。

473, 474, 471 の順番にマージされていくのが望ましい。そろそろコミット権をくれたりしないかな？と思ったりもする。というのは、タイミングの問題で action の job が落ちたり、バージョン上げるだけの pr とか、自分でマージしてしまえばいいと思ったりする。

hugo で書いた記事に目次を生成する

お手伝い先のテックブログは hugo で運用されている。記事の目次がないなと気付いて追加してみた。hugo v0.60.0 以降のバージョンなら標準で目次生成の機能をもっている。

<aside>
  {{ .TableOfContents }}
</aside>

デフォルトはヘッダー2レベルより下の目次を生成する。レベル1も生成したい場合は config.toml に次の設定を追加する。

[markup]
  [markup.tableOfContents]
    startLevel = 1
    endLevel = 3

考えないという傷のある現場

#ldap  #communication  #team building 

2時に寝て7時半に起きた。昨日からよく寝た。また心機一転。

ldap エントリーの crud api

先週から ldap クライアントや そのプール を実装して結合テストも一通り書いていた。今日はそれらを使った crud な web api を一通り実装した。クライアント実装もテストもしっかり出来ているので後は時間の問題で1つずつ確認しながらコードを書いていくだけだった。こういう作業になると、まとまった時間があればすぐに終わる。他のメンバーのコードレビューをみたり、設計の話しをしたり、他に意識を取られてあまり自分の作業に集中できなかった。

言葉が通じないもどかしさ

先週「参考にして」と指示したものが「全コピー」で驚いてしまった。私がいくつか指摘したらすぐに削除し始めてさらに落胆した。自分の頭で考えて作業していないようにみえる。

開発というお仕事は自分で考えて、コードの1つ1つに明確な意図や根拠をもって書くものだ。もちろん、情報不足や設計に自信がもてなくて一時的に曖昧な実装にするときもあるけれど、それは懸念事項として把握しておくことで将来対応すればよい。基本的に追加するコードにはすべて意味がある。

他人が分からなくても自分が理解できているのなら、自分の考えを説明し、それが論理的であったり筋が通っていれば、私は自分の考えと違っていても構わない。説明できないコードを追加して、ツッコミを受けてなにも説明できない状況をみているのは本当に悲しい。

山田ズーニーさんの著書に書いてあった「考えないという傷」を思い出した。

来週の出張準備

#document  #ldap  #issue management 

1時に寝て何度か起きて6時半に起きた。気分転換も兼ねた非日常の小旅行を終えてまた元の生活へ戻していく。

ドキュメント書き

昨日の続き。ドキュメントの一部レビューをお願いしているところがあるので別のところのドキュメントを書いていた。その過程で ldap の anonymous bind の設定ができないような制御になっていることに気付いてその設定を修正したりした。ドキュメントを書いていてバグをみつけた。

近況報告の資料作り

四国から帰ってきたばかりなのに来週は東京へ行かないといけない。開発はほぼ完了しているのでなにも憂いはないが、出張のタイミングで大きなふりかえりや次の開発フェーズの要件の発散などもやりたい。そのための資料の準備がまったくできていないことに昨日の夜、気付いた。明日・明後日ぐらいで準備して、できるだけ事前に参加者に共有したい。いまは忙しくないのだけど、なぜか空き時間をうまく作れなくても毎日バタバタしている感がある。

今日は月例の近況報告の資料を作っていた。客観的に、このタイミングで私を契約終了としてもよいだろうし、私の感覚的には次の開発フェーズを3-4ヶ月みて、その後にチームのメンバーにこのプロダクト開発を委譲するといった段取りがよいのではないかと考えている。そういった話しも来週はしてくるつもり。長く残ったとしても今年度いっぱいが区切りとしてよいのではないかな。

組織やプロジェクト横断的なメトリクスの視覚化

#ldap  #go  #issue management  #information exchange  #visualization  #event 

0時に寝て4時に起きてもう1回ぐらい起きて6時半に起きた。

もうすぐ期限がやってくる。私が担当している issue 対応はあらかた終わってメンバーに「大きいもので見落としある？」って尋ねて「ない」って返ってきたのでもうクローズに向けて調整していく感じ。今週末から月曜日と3日間お休みする (土日も含めて休むというのも変ではあるが) ので一安心。

dirsync 周りのリファクタリング

ずっとレビューが放置されていた。おそらくいま go-ldap のプロジェクトで最も活発なメンテナーが夏休みだったのではないかと推測する。昨日帰ってきたようで怒涛のレビューをされていて、私が3週間前に送っていた pr もレビューしてくれた。

概ね同意してくれて public な関数名をより適切な関数名に変えたところを、1度公開したものは互換性を維持するために deprecated のコメントをして残しておいてと言われたところだけ修正した。修正後、数時間ですぐにマージしてくれた。感謝。

go-ldap にいくつかコントリビュートした機能はうちのプロダクトのシステムに使われていて、それなりの qa テストをやった上で動いているので一定の品質は担保していると思う。直近1年間のコントリビューター を参照すると、私は2番目に貢献しているようにみえる。こういう見える化が自分のモチベーションになるならそれはそれでよいと思う。

組み込みの課題管理のプロダクトを作る上で、個人がみたいメトリクスを簡単に集計できるような機能を提供しようと考えている。それは自分が伸ばしたいスキルやプラクティスに対して、会社やプロダクトを横断的に計測できる仕組みがあるといいと私は考えている。とくにいまどきはプログラマーが転職するのは当たり前だが、転職したら前の会社でやっていたメトリクスがみれないとか、別の会社でのメトリクスと相対比較したいとか、そういうニーズはあるなと私自身が感じているからでもある。

go イベントのパネルディスカッション

mercari.go #23 Go1.21 パネルディスカッション オンライン開催 に参加した。視聴者が少なかったのか、youtube のコメント欄でちょくちょくツッコミもいれたら現場で拾ってくれておもしろかった。私が関心のあった話題を3つあげてみる。

gonew の提供

For a long time now, we have heard from Go developers that getting started is often the hardest part.

Experimenting with project templates

go で新規プロジェクトを始めるときにテンプレートからプロジェクトのレイアウトを作ってくれるユーティリティとして gonew というツールが公式から提供されたらしい。知らんかった。私も新しいリポジトリ作るときに標準的なものはファイルを基本コピペしているのでこういうのできれいに作れると嬉しいかもしれない。 

derrors の是非

pkgsite という pkg.go.dev というサイトのリポジトリの internal として実装されている derrors というパッケージがある。defer を使って必ず関数がエラーを返すときに wrap するという、ユニークな発想で実装されたツール。明示的なコードを書くという go の文化とはあわない気はするけど、ユニークな使い方ではあるのでおもしろい。

この延長でエラーが発生したときにレポートを生成する derrors のユーティリティもあったりする。google がやっていることだから、わりと開発者間でもこれと同じものを自前で実装する開発者が増えているといった話しも聞く。

go 2 はもうリリースされない

The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. Go 2 in the sense of being the major revision of Go 1 we started toward in 2017 has already happened.

Backward Compatibility, Go 1.21, and Go 2

これまでの go の言語処理系の開発の中で非互換な変更について「go 2 で」とプロポーザルだったり、issue の議論で先送りされてきた。最近コア開発者の Russ Cox 氏が (現時点で) go 2 はもう出ないと宣言した。go は既存のプログラムをコンパイルできない状態で新しいバージョンを出すことはしない。この背景の1つとして、誰もがジェネリクスの導入で go の互換性は崩れると思っていたものが互換性を維持して導入できたことが大きいと思う。(現時点で) go 2 はもうリリースされないらしい。

openldap サーバーのデバッグ

#ldap  #debug  #testing 

1時に寝て3時に起きて5時に起きて6時半に起きた。あとひと踏ん張りなのでこのまま突っ切る。

openldap 2.5 の ldappasswd の振る舞い

openldap サーバーでパスワードを変更時の平文パスワードを連携するために カスタム overlay モジュール を使っている。前回の改修をしたときは openldap 2.4 向けのみの振る舞いを検証していた。今回は開発フェーズでは openldap 2.5 向けにもモジュールをビルドしてパッケージングしていた。その qa テストをしていて ldappasswd だけ、意図したパスワード連携が行われないという。

開発時に私が振る舞いを検証したつもりが ldapadd, ldapmodify は確認済みだったが、ldappasswd の確認をしていなかった。これは完全に私のミスで2つのフックポイントに対してカスタム overlay モジュールが動くのだから ldappasswd も大丈夫だろうと見通していた。しかし、そうではなかった。それぞれにフックポイントのコールバック設定があって、フックポイントもロジックが違うのだから当然ではあるのだけど、ちゃんと動作検証をしないといけないという、初歩的なミスをした。こんなこともあるんやと反省した。

gdb でデバッグしていて原因は 2.5.3 に含まれる次の修正だとわかった。私が検証していた openldap サーバーのバージョンは 2.5.14 だった。

簡潔に言えば、なんらかの不具合対応でもともと設定してあるコールバックを別のものに上書きしていた。カスタム overlay モジュールが設定したコールバックが別のものに上書きされてしまって意図した振る舞いをしないという現象が起きていた。これは明らかに openldap のリグレッションなので 2.5.15 で修正されてた。

たまたまピンポイントにバグを踏んだ形にはなったが、qa テストという別の人がテストをする仕組みでこのバグを検出できたことがうちの開発の品質基準を担保していることの表れでもある。

生きるということは嬉しいこと半分、辛いこと半分なのですよ。 采王

3つめのテックブログ

#drink  #go  #ldap  #writing  #motivation 

2時に寝て何度か起きて7時に起きた。朝から弁護士さんにメールの返信をしたりしていた。午前／午後と普通に運用ツールの開発をして夕方に勉強会をして、夜に軽く呑みに行ってきた。

go-ldap テックブログとその勉強会

水曜日から テックブログの執筆 に着手して、木曜日のお昼には下書きを書き上げて社内レビューをお願いしていた。ldap プロトコルの振る舞いについて調べたことを書いた。あまり自信はなかったけど、社内のシニアエンジニアにレビューしてもらって、よく書けているとコメントをもらってシンプルに嬉しかった。いま開発の佳境のしんどい時期に、非開発以外のことに時間をとって記事を書いて報われた気持ちになった。

今日のチーム勉強会は私が担当だったのでこのテックブログの記事を解説した。実際に go-ldap のソースコードを一緒に読みながら進める。書いたり話したりすると、ちゃんと自分が理解できているかどうかを確認ができる。そして、コードを読みながら説明しているときに、記事に書いてある内容が一部間違っていることにも気付けた。こういう体験の繰り返しで私は自分を信頼しないことを学ぶ。私の浅い理解や未熟さを実感する機会があって、また次にがんばろうというモチベーションにもつながる。

自身の理解度の確認やチームへの共有、モチベーションコントロールなど、複数の意味で自分が書いたテックブログの記事を解説する勉強会はいいように思えた。

思い入れのあった内容を書いて公開してしまうと、燃え尽きのような、少しやり切った感を感じていた。しかし、開発はまだ佳境の途中なのでここで立ち止まることはできない。それで呑みに行ってみた。とくに目的なくみつけたお店に初めて入ってみた。普通の居酒屋よりちょっとだけ値が張る感じの、落ち着いたお店で、私よりも少し年配 (にみえる) マスターが1人でやりくりしていた。軽く話しながら晩ご飯を食べれてやや救われた。また行ってみようと思う。