Posts for: #2023/09

お休み前の勉強会

22時に寝て24時に起きて2時に起きて4時に起きて6時に起きた。晩ご飯食べてからオフィスに戻る元気がない。本当は明日の出張に備えて今晩、実家へ帰ろうと思っていたが、まったく準備ができていないので明日の早朝に帰ることにした。

slog 勉強会

チーム勉強会向けに、今日は軽い話題として slog のブログ記事をピックアップしてみた。この内容を deepl で翻訳して社内の wiki に書いてそれをメンバーと共有した。

うちのプロジェクトの logger はすべて slog に移行済みではあるが、一部 slog を使う前に実装したログ関数があって、そのカスタムログ関数の移行だけまだできていない。アプリケーションの振る舞いには影響を与えないし、急ぐ必要もないので先送りにしているだけ。次の開発フェーズでカスタムログ関数周りもすべて移行して slog で万全の状態にしたい。そのための予備知識として slog でこんなことができるという全体像は理解できた。とてもよい記事だったと思う。

LT 資料の推敲

先日 LT 資料のたたき台 を作成した。いくらか寝かして週のどこかの空いている時間に推敲しようとずっと頭の中にはあったものの、現実にはさぼっていて前日に最終見直しをしている。でも、見直した方がよいところのアイディアは2-3個思いついてはいる。少し手直ししたら明日のイベントに備えて早めに寝る。

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

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 サーバーのデバッグ

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 テストという別の人がテストをする仕組みでこのバグを検出できたことがうちの開発の品質基準を担保していることの表れでもある。

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

開発フェーズの完了まであと2週間

0時に寝て何度か起きて7時に起きた。オーバートレーニング気味で夜帰ってきてゆっくり過ごしている。

定例会議

次のマイルストーンでこの開発フェーズを完了させる。その最後の打ち合わせとなる定例会議。話題が多過ぎて、始める前から今日の会議は1時間におさまらないんじゃないかと話しながら始めて10分ほどオーバーして終えた。会議時間が私の感覚とも一致していてよかった (違う) 。

qa テストでいろいろ issue が洗い出されていて、その中のアーキテクチャや仕様の抜本的な見直しを検討するのが2つ、管理画面の ui/ux に関する設計の2つ、よいことではあるが、私の設計の目が及ぶ範囲を超えて issue が上がるようになりつつある。本当はフロントエンド向けに ui/ux デザイナーがいれば画面設計について委譲したいところだが、そんな人はいないのでチームで話し合い、私が方針を決めて暫定的に修正していく。

また致命的な issue は出ていないという私の認識から、次の2週間でこの開発は収束させるという合意を行った。やや qa テストや issue の収束は遅れ気味ではある。いまから慌てても大きく変わることはないし、このチームは十分に私の課題管理の慣習にしたがって作業しているので、このまま成り行きでもうまく着地できるんじゃないかなと楽観的には考えている。その感覚は過去の経験からも来ているのだろうけど、もうこの歳になると脳ができることを自動的に判断している気がする。できるとわかっているから不安や焦燥感といった危機を感じられない。悪い言い方をするとさぼっているだけという見方もあるが、そういう感覚をここ2-3年で実感するようになってきた。

会議が終わってから私は reflection 関連のバグを2つ直した。

週末遊んで月曜日を迎える

21時に寝て何度か起きて7時に起きた。決して夜更ししているわけでもないのにずっと疲れている感があって早めに寝ていた。それでさらにお仕事が溜まる。

qa テストとバグ修正

先々週から qa テストが始まっていて、私はあまり参加できていないけれど、上がってくる issue のトリアージや致命的なバグの修正、インフラ周りの不具合の修正などをしている。1つは1つは難しくない小さい粒度のものだけれど、他の issue との関連があったり、アーキテクチャや既存の仕様そのものを見直した方がよいものもあったりと、背景の調査に時間がかかっていて、思ったよりも「ちぎっては投げちぎっては投げ」といった対応は取れていない。issue の優先順位付けしようにも、先に解決しないといけない issue があったり、この仕様はそもそもおかしいとか、よいことではあるのだけど qa でみつかる issue のトリアージが難しくなっている。それだけメンバーのシステムへの習熟度が上がって精度の高い issue をあげられるようになってきたという現れでもある。私がまごまごしているのは紛れもない事実ではある。

LT 資料のたたき台作り

3時に寝て朝起きたものの、体調がよくなくて10時まで寝てた。朝ご飯をゆっくり作って食べてからお昼前にオフィスへ着いた。

昨日の翻訳の手直し

昨日の推敲途中で公開した記事 の手直しから行う。後半眠くなってしまいチェックできてなくて、先に公開しちゃえってやったらいろいろ不備があって直していた。どうせ誰も読まないだろうと思ったら、ぽつぽつアクセスが増えてきてお昼ぐらいにはホットエントリーになっていたかもしれない。午前中に読んだ人はひどい記事の体裁でごめんなさいという気分だ。

この記事はうちの会社の社内 sns にしか共有していない (たぶん知人もなにもしていない) のに、ホットエントリーになっているのをみて、本当によい記事ならほとんど宣伝しなくても勝手に広まるというのを実感した。私は基本的に sns をやめようと考えていて facebook 以外はほぼやっていない。facebook を年賀状のような使い方にしている。年に1回、私の近況を見にきた方が近況を分かるようにだけしている。あとはお仕事の依頼がたまにくるのでそういった人たちとのインタフェースとして置いておく。とはいえ、依頼がきても9割は断るしかないというのがうちの会社のいまの辛いところでもある。以前2つの会社のお仕事を掛け持ちして大失敗したため、色気を出さず、できないお仕事は受けないというのを徹底している。

LT 資料の作成

来週 オープンセミナー2023@香川 で LT してくる。そのための資料のたたき台を作った。課題管理に関する話題なので会社として発表してこようと思う。会社用のスライドテンプレートを使って2回目の発表となる。こういったマーケティング活動も、本当は昨年からどんどんやるつもりが、まったくお仕事がうまく進んでなくて後手後手後手といった状況。昨年は1年の計画のうち1割しかやっていなかった。

  • 貧すれば鈍す
  • 窮すれば濫す
  • 貧乏暇なし

こういう言葉が似合う。がんばってもがんばってもお仕事が終わらず、もしかしたら加齢でパフォーマンスも落ちているのか、モチベーションコントロールが出来てなくて集中力が低いのかもしれない。あと実家のいろいろも少しある。そんなことを言ってももうどうにもならんので、今年初めてのマーケティング活動なのでがんばって話してこようと思う。

linkedin による dm の効果

22時に寝て何度か起きて6時に起きた。もうがんばれない状態。本当はお仕事すべきではあったんだが、モチベーションが売り切れてしまって違うことした方が気分転換になりそうなので翻訳していた。

ストレッチ

先週が疲労のピークだった気がする。先週よりはましになったものの、右足全般がやばい感じだった。かなり辛かった。ここ1-2週間、歩いていて知人からも足悪いの?と聞かれるぐらいには、まともに歩けなくなっているようだ。あと何年歩けるのだろう?という危機感も少しある。腰もやや右側の張りが強かった感じはした。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。先週よりは少しだけ改善した。ただお仕事のピークは超えたのでこれから少しずつ回復していくといいなと想定している。

deepl で翻訳したものの手直し

来週の LT 発表ネタの準備。

ある英語の記事を紹介するにあたり、その日本語翻訳を用意しておこうと考えた。要約をちょろっと話して詳細はこれ読んでねみたいな LT にしようと思う。先週から著者に翻訳の許諾をしてほしいというメールを送っていたが1週間経っても返信なし。著者との別のコンタクト方法の1つに linkedin があった。linkedin でメッセージを送ると3時間後に OK の返信がきた。そっか linkedin だと、相手がどんな人かといった情報がわかるからメールよりも返信するモチベーションになりやすいのかもしれないと気付いた。少なくともスパムではないと確認できて安心できる。今後は linkedin で dm を受け付けている人には linkedin を積極的に使っていこうと思った。

今回は deepl を使って翻訳しようと考えていた。プロライセンスを購入していれば、翻訳した成果物の著作権を主張しないと規約に書いてある。基本は deepl で翻訳するものの、「てにをは」を直したり、スキップされた文章を再翻訳したり、訳文がおかしいところを見直したり、あとテーブルや図の英語を手入力して翻訳したりとか、あと細かいレイアウトの調整とか、文章量が多かったのでそういった細々したことをやってたら7時間ぐらいはかけたと思う。

ポッドキャストを聞きながら手を動かしていたり、途中で晩ご飯を食べに行ったりしながら、お昼から始めて夜中の2時前ぐらいになって、もう眠くなって推敲に疲れて、半分ぐらいチェックし終えたところで公開しちゃうことにした。公開した方が慌てて直すモチベーションになるから意図的にそういうことをするときもある。

今日はもう眠くて無理で公開後、家に帰ってすぐに寝てしまった。

クレームへの階段

0時に寝て何度か起きて6時に起きた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。先週は多忙でお休みした。今日の議題はこれら。

たまたま X (twitter) でスクラム批判しているツィートを教えてもらってリンクにあるように Scrum is a cancer. というインパクトのある書き出しで聴衆を一気に掴んで盛り上がっていた。多少の誇張はあるものの、内容も真っ当で私が読んでみてもそんなに違和感がなかった。スクラムの懸念をうまく言語化したポストになっていたと思う。その延長で他にも、見積もり、フィードバック、ストーリーポイントにも言及していて、これらの話題についてはらさんと雑談してみた。はらさんとは1-2年前からスクラムの話題で何時間も話しているので、もうお互いに食傷気味ではある。ただ時事ネタなのと1年ぐらい経ったらアップデートもあるかな?という期待もあって話題に選択してみた。次のような意見が出た。

  • スクラムの開発プロジェクトをそんなに経験している開発者は少ないから主語が大きくなりがち
  • マネージャー入門としての、スクラムという開発方法論を評価してもよいのでないか?
  • 「スクラムにはマネージャーいない」と骨髄反射で返答をよくもらうがそれは理想論ではないか?
  • スクラムの失敗と事業/業務の失敗は違う
  • スクラムは毎日見積もり、デイリースクラムで確認できるというメリットがある
  • スクラムはチームの限定合理性を重視するため、個人の限定合理性を重視するメンバーを排除できる
  • スクラムの懸念の1つに全然できていないのに「できている」というメッセージを出し過ぎるのではないか?
  • ソフトウェア開発は前提として見積もりできないという認識をもつべき

お腹いっぱいなので詳細はあまり書かない。

オフィスの担当者との電話

先日の 暑さ対策委員会 の続き。

昨日、運営会社にその後の進捗を確認するために電話したらお休みだったので再度電話した。昨日もコールバックすると言いながら15時過ぎてもコールバックがなくて、もういい加減エスカレーションして偉い人に正式なクレームをあげようと考え始めていた。ようやく電話つながったと思ったら通話の音質が悪くて話しているうちに切断して、その後もつながらない。本当にイライラがつのる。2回目のコールバックで話していると、エアコンの工事によって隣のオフィスの人たちは問題ないと言っていたといったコメントが出てきた。

私のイライラが最高潮に達したのはこのとき。私はこれまでもずっと隣のオフィスの社員さんと暑さどうですか?という会話を何度かして先方も室内は暑いという話しを聞いていた。隣のオフィスの社員さんが問題ないなんて言うわけがないと思って、そのまま隣のオフィスへ言ってそこの社員さんにも電話に出てもらった。もちろん隣のオフィスの社員さんはこの件について一切やり取りしていない。社員さんも「(暑さについて) すぐ分かるから現場に来いっ!」って怒っていた。

ほんとその通りで7月の中旬からずっと伝えている。何もしていないわけではないのは理解するが、現地で確認したらこれまでの施策の効果がないことは一目瞭然である。一切確認せずに作業したから問題ないと判断して放置していたようにみえる。一連の対応が終わったときに正式なクレームとして運営会社にあげようと考えている。

  • 1ヶ月半の間に5回電話して一度もコールバックも進捗報告もなかった
  • 効果が出ていないことは報告しているにも関わらず、なんら施策を検討していない
  • 現地で確認すれば、ひどい暑さであることがすぐわかるのに1度も調べようとしなかった