なんか疲れていて帰ってきて晩ご飯食べたらすぐに横になってた。0時に寝て5時半に起きて7時に起きた。

プロジェクトのスケジュール調整

先週からお手伝い先の経営陣には一報を入れてあったのだけど、お昼にメンバーと 1on1 してスケジュール的に厳しそうという再確認をして正式にいまの開発スケジュールに対して1マイルストーン (2週間) を延期することに決めた。先週の時点で残タスクの状況と進捗をみていて厳しそうだとは私の視点からもみえていて、ある意味の予定調和ではある。いまの開発は昔のように残業したり休出したりしないため、遅れていることがわかった時点でできることは機能を減らすか、期日を延期するかの2択しかない。今回は内容的に機能を減らすことはやりにくいため、延期するという施策しか私には打ち手がなかった。

原因としてもっとも大きいことの1つは 新規メンバーが3ヶ月間なにもしなかった ことであり、新規メンバー向けに用意した開発機能を既存メンバーで吸収しきれなかったことになる。既存メンバーに責任があるわけではなく、私がもう少し速く決断できなかったことの影響がこの遅延につながったというものではある。これはまた開発の大きなふりかえりの中でチームで議論したいと思う。

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。前回の所感はここ 。今回は「今年よかったこと、来年やりたいこと」をそれぞれに発表する会になった。私は先日作成した 2023年ふりかえりスライド を参加者に共有して説明した。

• よかったこと: 課題管理の PoC を実務の開発で実践して成果が出ている
• 来年やりたいこと: 実家の離れにコワーキングスペースを作る

参加者みんなが農業に関心をもっていて、IT x 農業という取り組みで新しい挑戦をすることに関心を示す人は多い。これは三ノ宮.dev においても同様で農業に関心をもっている人は多い。農業をビジネスにするのはとても難しいし、大変なことだと私は認識しているが、別にビジネスにならなくてもコミュニティ活動の一環やライフワークの1つとして、仲間たちと価値観を共有するための触媒もしくは土壌としてよさそうに考えている。いまのお手伝いのお仕事を終了したら、来年はいとうさんと一緒にコワーキング + 農業でうまく運営している先行事例を視察に行って、それらを研究して、なにかしら新しいことに取り組んでいきたいと思う。

1時に寝て5時半に起きて7時半に起きた。なんか週の前半からバテている。

gitlab ci/cd の dind で mongodb のレプリカセット接続ができない

先日対応した mongodb のレプリカセット対応 で残った最後の課題。ローカルで実行すれば結合テストは動くが、gitlab ci/cd 環境では動作しないという問題が残っていた。gitlab-runner をローカルで実行できる ようにして、設定やパラメーターを変えたり、デバッグコードを埋め込んだり、コンテナに attach して振る舞いを確認したり、いろいろデバッグして原因はレプリカセット接続におけるホスト名の解決がコンテナ間でできていなかったことがわかった。

mongodb の結合テストは dockertest を使って実装している。これを gitlab ci/cd で動かすには dind を有効にする必要がある。dind 環境では2つのコンテナを使って結合テストが実行されるわけだが、テストが実行されるコンテナと mongodb コンテナが起動するコンテナの2つが生成される。このときにテストが実行されるコンテナから実際に mongodb が起動するコンテナのホスト名の解決と、mongodb が起動するコンテナ上での自分のホスト名の解決の2つが成立していないとレプリカセット接続ができない。要は1台のローカルホスト上で結合テストを実行するのと、2つのコンテナ上で実行されるのでは設定を変更する必要があるということに気付いた。

具体的には dockertest の次のパラメーターを、実行環境から解決するホスト名を考慮して設定すればよいと気付いた。

pool.RunWithOptions(&dockertest.RunOptions{
    ... 
    Hostname:   executor,
    Env: []string{
        ...
        fmt.Sprintf("MONGODB_ADVERTISED_HOSTNAME=%s", executor),
        ...
    }
})

たったこれだけの修正だし、現状の動作の振る舞いが分かればすぐに直せるものではあるけれど、このデバッグにはまた2-3時間を費やした。mongodb のレプリカセット接続はなかなか大変。

23時頃から寝始めて3時に起きて5時半に起きて8時過ぎに起きた。久しぶりに寝坊した。

gitlab-runner のデバッグ

mongodb のレプリカセット対応して、ローカルでは結合テストが動くものの、gitlab ci/cd 環境では動かなくなった。gitlab ci/cd は GitLab Runner によって提供されている。そのデバッグのため、ローカルに gitlab-runner をインストールして調査した。

GitLab Runner のインストール ドキュメントにそれぞれの OS 向けのドキュメントがある。Debian/Ubuntu/Mint 向けのインストール手順を行う。

$ curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
$ sudo apt-get install gitlab-runner

$ gitlab-runner --version
Version:      16.6.1
Git revision: f5da3c5a
Git branch:   16-6-stable
GO version:   go1.20.10
Built:        2023-11-24T21:11:36+0000
OS/Arch:      linux/amd64

.gitlab-ci.yml があるディレクトリへ移動して、ジョブを指定して実行する。ローカルでの変更内容を検証するときはブランチにコミットしないといけない。コミットしていないと次のワーニングが表示される。

WARNING: You most probably have uncommitted changes. 
WARNING: These changes will not be tested.         

dind なジョブを実行するときは --docker-privileged で特権を付けて実行する。環境変数は --env KEY=VALUE で渡せるが、CI_JOB_TOKEN のような組み込みの環境変数は上書きできない。

$ cd path/to/repo
$ gitlab-runner exec docker --docker-privileged ${ジョブ名}

1時に寝て5時半に起きてだらだらしてゲームをちょっとやって7時半に起きた。なぜか分からないけど、実家で寝ると普段3時間ぐらいしか睡眠できないのが4-5時間に伸びる。気圧？空気？土地の守りみたいなもん？夕方には神戸に戻ってきていたが、寒さで凍えたのもあってそれから作業する元気がなかった。

田んぼ

8時からトラクターで田んぼを耕す。昨日は暖かったのに一晩寝たら急に冷え込んだ。うちのトラクターは旧式なのでエアコンはついてなく、風を遮るものもないので風の強い気温の低い日はめっちゃ寒い。3時間ほど耕して畝を作った。写真は撮り忘れた。今回耕したところの畑は高低差ができてしまってよく耕せるところとそうじゃないところができて、あまりうまく耕せなかった。いずれ平坦にならさないといけない。

田んぼを終えてから近所の観光客向けの食堂でぶり丼を食べた。これで1,250円とやや割高ではあるけれど、ぶりの刺身は新鮮で質のよく、久しぶりにおいしいお刺身を食べた。若い子にとっては量が物足りないかも？だが、中年にとってはこのぐらいの量でちょうどよい。

スマートキーの電池交換

車のメーターパネルにスマートキーの電池残量低下という案内が出るようになった。調べてみると、スマートキーは常に電波を放出しているので短くて1年、長くても2年で電池が切れるという。ちょうどいま1年近く乗ったところなのでうちのスマートキーは1年程度で電池が切れるようだ。電池が切れたら車に乗れないのかな？と調べてみたらそうでもなくて、スマートキーに内蔵キーと呼ばれる物理キーも用意されていてそれでドアの施錠の開閉ができて、さらにエンジンのスタートも電池が切れていてもできる仕組みになっているそうな。そりゃそうか。電池切れる度に車に乗れなくなっていたら世の中もっと混沌としている。

• Hondaスマートキー
• Hondaスマートキーの取り扱いと電池交換

ストレッチ

土日は実家に帰っていたので日曜日の夜にストレッチを受ける。土日に車で実家との往復をすると腰に負荷がかかる。さらに田んぼを耕すためにトラクターに数時間座って操作しているのでさらに追加で負荷がかかる。その目論見の通り、トレーナーさんの言葉からも、自他ともに今日は腰がもっとも疲弊していた。今日の開脚幅は開始前152cmで、ストレッチ後156cmだった。ストレッチ後に晩ご飯食べてからオフィスで作業するつもりが、外が寒くて出掛けるの億劫になってそのまま家でだらだらしていた。

1時に寝て3時過ぎに起きた。あまり眠れないことのメリットとして普通に寝ても2-3時間で目が覚めるのだから朝早くに出掛けるときの寝坊リスクが減る。起きてから準備をして5時半過ぎには神戸を出て7時前には実家に着いた。6時半ぐらいまでは外は暗く、朝なのに暗い道を帰ることになった。

夜は寝て朝に出掛ける

車があるのでいつでも帰れるのだが、最近は夜に帰るよりも朝に帰ることの方が多い。平日の夜はあまり時間がない。18-19時にお手伝い先のお仕事を終え、晩ご飯を食べ、次に自社のお仕事をしたり日記を書いたりしていると21-23時ぐらいになる。それから準備して帰るのは疲れていてやる気がしない。その日たくさん働いたーと思って帰ってきたらもう何もやる気はなくて、漫画読んだりアニメみたりゲームしてそのまま寝るというのが日常。翌日の出発準備すらやらない。

寝て起きたらまた新しい1日が始まるのですべてがリセットされる。この日常の生活のリズムを大きく崩さないという意図でも、朝起きてから行動するのが性にあう。

一回忌

この前は 初盆 だった。

10時から住職に来ていただいてお経をあげていただく。今日は住職の斜め後ろに座ったので住職の様子を観察していた。お経をあげているときに折本をめくりながらお経を唱えている。あまり折本をみているようにはみえないが、進捗にあわせて折本をめくっていることに気付いた。いつも通り、住職にお経をあげてもらい、その後、出席者も真言の折本をみながら一緒に唱える。折本は裏表あるので、表面が終わったときにもう終わりかな？と油断していると、裏面のお経が始まるので初心者はちょっと驚くかもしれない。今日もってこられた真言の折本はいつもと違うものだった。

終わってから住職の法話を聞く。1年過ぎるのが早いといった趣旨でお話をされた。実は住職の父親の命日と父の命日は1日違いになる。住職にとっても近いうちに一回忌があるらしい。その想いも含めて話されていたのだろう。この人はこういう人だと型にはめて決めつけで話すことは多いが、人の本性のようなものを1つの側面から語ることは難しくて、さまざまな側面があることに、亡くなっていなくなってから気付くことも多いという。亡くなって1年たって、こんな人だったという輪郭もぼやけてきて、いろんな側面をもった人だという解釈でいいのではないかといった話だったような気がする。そして、1年経って、この場に来られた出席者の縁、来られなかった人たちの縁、いろんな縁があると話されていた。12月に会う人はみんな口癖のように1年が早かったと私の周りではいう。私もまたまったく同じ感覚で、この1年はなにをしていたか思い出せないぐらいに1年が足早に過ぎていく。幸い、いまは日記を書いているので過去の書いたものを読み返せばこんなことをやっていたなと思い出すきっかけにはなる。そうやってコンテンツを積み重ねることがいつかなにかの役に立つことも知っている。

11時から近所の和食料理屋さんに移動して法要の食事とする。だいたいいつも2時間ぐらいで早めに始めると13時に終わって、休日を潰すといったこともなくてよいと思う。

前日に出席者の1人が来られ、腰を痛められて法事に参加できそうにないということだった。直前にキャンセルになってしまったので料理屋さんに電話して、お代は支払うが持ち帰れるお膳を作ってもらえないかと相談したら、立派な法要箱膳をこしらえてくれた。普通のお弁当のようなものを想定していたらその4倍ぐらいあるような箱膳にしてくれて、よい意味で期待を上回るものだった。お食事を解散してからその足で親戚の家に訪問して手渡ししてきた。

22時頃に寝てしまって1時に起きて5時に起きて6時過ぎに起きた。とくになにもしていないのにバテている気がする。今週はずっと mongodb のレプリカセットの調査やインフラの移行作業などをやっていたせいか、普段よりもエネルギーを消費しているのかもしれない。朝から疲労困憊でオフィスへ向かった。

docker のコンテナネットワークの調査

docker のコンテナネットワークから解決できる名前がなになのか、よくわかってなくて、その調査のためにサンプルの compose サービスを作った。

• https://github.com/t2y/docker-compose-sample

myimage から nginx のコンテナの名前解決がどうなるかを試してみる。

c67a5ca94a77:/app# dig +short 00c719491558
192.168.240.3
c67a5ca94a77:/app# dig +short mynginx
192.168.240.3
c67a5ca94a77:/app# dig +short nginx
192.168.240.3
c67a5ca94a77:/app# dig +short yournginx
192.168.240.3

基本的にはサービス名、コンテナ名 (container_name)、コンテナー ID、ホスト名 (hostname) はすべて名前解決できる。hostname があるときはそのコンテナの /etc/hosts にその名前が追加され、ないときはコンテナ ID が追加されていた。

yourcontainer:/app# cat /etc/hosts
127.0.0.1	localhost
...
172.18.0.3	yourcontainer

冬の開発合宿の準備

日程を決めたのが5月末 で、うちの会社のワークスペースに slack のチャンネルを開設したのが10月。現時点で7人の参加者がいる。もうこのメンバーでいいかなと考えている。今回はコミュニティのワーケーションイベントというより、自社の開発合宿という体をとっている。スポンサーとしていくらか会社からお金も出す。その理由の1つは slack チャンネルにログを残したいという意図がある。コミュニティの slack だとフリープランになるので3ヶ月以上過去のログがみえなくなってしまう。それを解消するには自社の有料プランの slack チャンネルに置いておくのがもっともログを制御できて嬉しい。

城崎温泉では11月から 🦀 が解禁となって、今年は冬に行くので 🦀 を食べるというのも目的の1つ。チャンネルで盛り上げようと、たまに城崎温泉の記事を貼り付けたりしていた。そろそろ、メンバーと顔合わせの情報共有の打ち合わせをしようと思って調整さんを作った。他の人たちは、わざわざうちの slack のワークスペースにゲスト参加しているから、あまり無理強いをせずに情報共有できるようにしておきたい。たった1つの、ほとんどやり取りしないチャンネルのために slack のワークスペースをオープンしておかないといけないという用途はなかなか面倒だ。私が逆の立場でもそう思う。どうにか普段使っているワークスペースから、必要なときだけ連携できるような仕組みがないだろうか？

年末・年始の情報共有の打ち合わせへ向けて旅のしおりも準備していく。日々の業務に忙殺されて後回しにしがちなので自分を追い込むためにも予定を入れた。

1時に寝て3時に起きて6時半に起きた。スマホで呪術廻戦のゲームを開いたまま寝てた。

サードパーティの mongodb コンテナへの移行

昨日の mongodb のサードパーティのコンテナイメージ調査 の続き。

レプリカセットの削除

基本的に一度作ったレプリカセットを削除することはないせいか、レプリカセットを削除するユーティリティは提供されていない。なんらかの理由でレプリカセットを再作成したいときは、レプリカセットの設定が保存されている local database を削除する。

またレプリカセットの稼働中に local database を削除することはできないため、mongod サーバーを --replSet を指定していない状態で起動させ、そのときに次のようにして local database を削除できる。

test> use admin
admin> db.grantRolesToUser("root", ["__system"]);
{ ok: 1 }
admin> use local
switched to db local
local> db.dropDatabase()
{ ok: 1, dropped: 'local' }
local> use admin
switched to db admin
admin> db.revokeRolesFromUser("root", ["__system"]);
{ ok: 1 }

コンテナを使ったレプリカセットの初期設定

bitnami/mongodb を使うと、ローカルのシングルノードでレプリカセットを使うには次のような設定になる。

  mongo:
    image: docker.io/bitnami/mongodb:7.0.1
    user: root  # デフォルトは非 root ユーザーで起動するのでローカルの開発環境なら root で実行した方が手間がない
    volumes:
      - ./volumes/mongodb:/bitnami/mongodb
    environment:
      MONGODB_ROOT_USER: "${MONGO_USER}"  # 認証ユーザー
      MONGODB_ROOT_PASSWORD: "${MONGO_PASSWORD}"  # 認証ユーザーのパスワード
      MONGODB_ADVERTISED_HOSTNAME: "mongo-primary"  # レプリカセットのノードを ip アドレスではなくホスト名で指定する
      MONGODB_REPLICA_SET_NAME: "myrs"  # レプリカセットの名前
      MONGODB_REPLICA_SET_MODE: "primary"  # プライマリノードとして設定
      MONGODB_REPLICA_SET_KEY: "my/replication/common/key123"  # キーファイルのコンテンツ (base64 でデコードできる値)
      MONGODB_SYSTEM_LOG_VERBOSITY: 0  # ログレベル
    hostname: mongo-primary  # コンテナの内外から解決できるホスト名を指定
    container_name: mongo  # コンテナ名 (docker container ls で表示される名前)
    ports:
      - 27017:27017  # レプリカセットを運用する場合はポート番号のマッピングを一致させる必要がある
    restart: "always"

この設定でレプリカセットを初期した場合、レプリカセットの initialize 処理は、次のような config/member をもつ。

members: [{ _id: 0, host : "mongo-primary:27017", priority: 5 }]

コンテナの内部からは mongo-primary というホスト名に対して、コンテナネットワーク内のローカル ip アドレスが解決される。

c67a5ca94a77:/app# dig +short mongo-primary
192.168.240.3

ここで host os 上のアプリケーションから mongo コンテナに対してレプリカセット接続をする場合 replicaSet=${レプリカセットの名前} のパラメーターを追加する。

mongodb://root:password@localhost:27017/?authMechanism=DEFAULT&replicaSet=myrs

これは localhost:27017 にレプリカセットの接続を試行し、接続できるとレプリカセットのメンバーが返される。

レプリカセットのメンバーには mongo-primary:27017 という設定が行われているため、mongo-primary というホスト名に対して host os 上で名前解決できる必要がある。そのために /etc/hosts に次の設定を行う。

$ sudo vi /etc/hosts
...
127.0.0.1 	mongo-primary

compass で接続した場合、レプリカセット接続であれば、レプリカセットの名前が接続情報として表示される。

ダイニングテーブル引き取り

実は火曜日にも長机を引き取りに行ってきて、今日はダイニングテーブルを引き取りに行ってきた。この3日間で2つもテーブルが手に入った。いつも目ぼしいと思ったものは、すぐに他の人と取り引きが成立してしまうのに、たまたま続けて私と取り引きが成立した。車で20分ぐらいの距離のマンションまで引き取りに行った。20時の予定を、19時10分には着いてしまって、先方も快く対応してくれた。私よりも見た目すこし年配の方で人当たりのよい感じの方だった。ジモティのやり取りはその人の性格が出るもので、受け渡しだけささっとやって余計な話しはしないパターンもあれば、愛想よく話しながら受け渡しをするパターンもある。先方によると、大事に使っていたテーブルのようにみえるので私も離れのオフィススペースで大事に使おうと思う。

23時に寝て3時に起きて寝たかどうか覚えていないうちに6時半になっていて7時半に起きた。

json を介した go の bool 値のバリエーション

go-playground/validator のバリデータには required というバリデーションオプションがある。しかし、このオプションは go のゼロ値でないことをチェックするという仕様になっている。bool のゼロ値は false となるため、リクエストした JSON データに false を設定していたのか、未設定だったのかの違いを検出できない。これはバリデータの問題ではなく、go の json ライブラリの制約のようなもので使い勝手のよい仕様とは言えない。私もこの振る舞いに起因する不具合に遭遇したこともあるし、こういうときにどうしたらよいかも過去に3回ぐらいは調べている気がする。

• How to validate bool #142

現時点での私の最適化は次のコードになる。データ構造として *bool 型にすれば、ポインタ型のゼロ値は nil となるため、true, false, nil の3値でバリデーションできる。しかし、私はこのデータ構造を好ましく思わない。というのは、内部的には true/false の2値でしか管理しないメンバーを、json のバリデーションのためだけに nil も許容する3値にすることがよい設計だと私は思えない。そこでバリデータによるバリデーションは諦めて、json の Unmarshal 処理をフックしてバリデーション相当の処理を自分で実装する。このやり方のデメリットはメンバーが追加されたときに自分で UnmarshalJSON() メソッドを保守する必要がある点になる。しかし、メリットとして内部のデータ構造の型は bool 型で扱える。一概にどちらがよいとは言いにくいかもしれないし、設計上の好みかもしれない。

type reqMyData struct {
	Name       string `json:"name"`
	View       *bool  `json:"view"`
}

type MyData struct {
	Name       string `json:"name"`
	View       bool   `json:"view"`
}

func (d *MyData) UnmarshalJSON(data []byte) error {
	var tmp reqMyData
	if err := json.Unmarshal(data, &tmp); err != nil {
		return fmt.Errorf("failed to unmarshal as reqMyData")
	}
	if tmp.View == nil {
		return fmt.Errorf("required view field")
	}
	d.Name = tmp.Name
	d.View = *tmp.View
	return nil
}

サードパーティの mongodb コンテナイメージ

先日の mongodb のレプリカセット調査 の続き。コードレビューをしていて bitnami/mongodb というサードパーティのコンテナイメージを使った方がよいのではないか？というコメントがあったのでその調査をしてみた。VMware 社が提供しているサードパーティのコンテナイメージらしい。

MongoDB(R) is run and maintained by MongoDB, which is a completely separate project from Bitnami.

まず MongoDB プロジェクトとはまったく別管理であることが書いてある。

Bitnami イメージを使用する理由

• Bitnamiはアップストリームソースの変更を綿密に追跡し、自動化されたシステムを使用してこのイメージの新しいバージョンを迅速に公開します。
• Bitnami イメージでは、最新のバグ修正と機能をできるだけ早く利用できます。
• Bitnamiのコンテナ、仮想マシン、クラウドイメージは、同じコンポーネントと構成アプローチを使用しているため、プロジェクトのニーズに応じて形式を簡単に切り替えることができます。
• Bitnamiのイメージはすべて、minideb（最小限のDebianベースのコンテナイメージ）またはscratch（明示的に空のイメージ）をベースにしています。
• Docker Hubで利用可能なすべてのBitnamiイメージは、Docker Content Trust（DCT）で署名されています。DOCKER_CONTENT_TRUST=1 を使用して、イメージの完全性を確認できます。
• Bitnamiコンテナイメージは定期的にリリースされ、最新のディストリビューションパッケージが利用可能です。

MongoDB®を本番環境で使用したいですか？Bitnami Application Catalogのエンタープライズ版であるVMware Tanzu Application Catalogをお試しください。

mongo の公式イメージは ubuntu をベースイメージにしている。ubuntu よりは minideb の方が軽いのかな？そしてちゃんと upstream にも追随しているみたい。このベースイメージの違いによるものかは定かではないが、結合テストのイメージも移行してみたところ、10-20秒ほど結合テストの実行時間が速くなった。割合にすると10%程度かな。

KubernetesにMongoDB®をデプロイするには？

Bitnami アプリケーションを Helm Chart としてデプロイすることは、Kubernetes 上で当社のアプリケーションを使い始める最も簡単な方法です。インストールの詳細については、Bitnami MongoDB® Chart GitHub リポジトリを参照してください。

Bitnami コンテナは、クラスタへの Helm Charts のデプロイと管理に Kubeapps と一緒に使用できます。

helm chart も提供しているようで、いずれクラウド版を作るときに MongoDB も k8s 上にデプロイする上でこのことは都合がよいように思える。

レプリケーションを前提とした初期設定があり、entrypoint スクリプトもいくつか読んでみた感じだと、きれいに管理されていて保守もちゃんとやってくれそうにみえる。

• https://github.com/bitnami/containers/tree/main/bitnami/mongodb

昨日、導入したばかりの公式イメージ + 自作スクリプトによるレプリケーション設定を廃止して、Bitnami のコンテナイメージを使うことに決めた。

0時に寝て2時に起きて6時に起きて7時に起きた。まぁまぁ普通に眠れた。

定例会議

いよいよこのマイルストーンを終えると、あと1つで機能開発の終わりとなる。いくつかの要因があって開発の進捗は遅れ気味になっている。メンバーがどうこうというわけではなく、私がうまく段取りを組めていなかったり、自身がマネジメントの業務をちゃんとまわせていないところが開発スケジュールの遅延につながっている。いまの状況は私が失敗したあのときのあれや、このときのこれから全体の進捗へ影響を与えているなとわかるぐらいにはマネジメントの動きが読めるようになってきた気がしている。読めるんだったら対応しろよというのはわかっているものの、モチベーションが足りなくて成り行きに任せていて成るようになっていないなといったところ。私のモチベーションが足らないところも含め、今フェーズの開発にはマネジメントの反省材料がいくつかある。

真面目にやった人を不当に咎める

昔から私はわりとワーカホリックだったので興が乗るとずっとお仕事をしていることが多かった。若い頃はやったらやった分だけ成果が出て評価されて、それはそれで楽しかったものの、30代になるとできて当たり前、成果のレベルがよほど飛び抜けていない限りは評価されることはなくなった。仮に10段階で例えると、若い頃は3しかできないと思っていた人が8ぐらいやると評価されやすいし、30代では8やって当たり前だと思われているから10やっても12やっても大差ないとみなされる。もはやお金のためにお仕事をしているのではないため、評価されなくても気にはならないし、いまは自分で契約の判断ができるので嫌なら契約を終了して別のお仕事を探せばよいだけという割り切りもある。

そんな中、昔からずっと思っていることが1つあって、真面目にやっている人たちを適切に評価しない上司が多い。要はなにも言わなくてもちゃんとやってくれているから放置するといった傾向がある。そして、さぼっている人たちや成果を出せていない人たちをかばう傾向がある。それはパフォーマンスが低い人たちを悪く言うと、さらにモチベーションを下げて、もっと悪くなるから励ますという意図があるのだと思う。しかし、その対応が度を過ぎると、真面目にちゃんとやった人たちのモチベーションを吹き飛ばしてしまう。その典型的な言葉が「みんながんばった」になる。実際は数人のコアメンバーが業務の大半をやっているのに上司は個々人の差異をなくしたがる。チームの一体感とか、空気を悪くしたくないとか、ハレーションを防ぐとか、いろいろあるのだろう。私は一緒に働いている人なら誰でも気付けるレベルの、みんながんばってないのに、そういった問題を指摘することもなく、なぁなぁで済ませるのをいくつもみてきて、これは日本の会社や組織で共通する傾向があると思う。なにを危惧しているのかわからないが、問題の本質に触れようとしないことが度々起こる。気付いたら対応しないといけないから気付いてないことにしたいと言い換えてもよいかもしれない。そういう状況をみると「またか」と思って私のモチベーションが落ちる。誰だって働きたくない。

私はよくやってくれている個人を、何度でも、よくやってくれていると明言して評する。がんばっていない人たちを咎めたりはしないが、がんばっていないのにがんばったとは絶対に言わない。状況によってはもっとがんばってほしいと言う。個人差があることを曖昧にしたりはしない。

23時に寝て2時に起きて6時に起きて7時過ぎに起きた。なんか微妙な寝方をした。

先日の mongodb のレプリカセットの調査 の整理をしてマージリクエストを作成した。共通鍵の keyFile をどう扱えばいいのか、わからなくて、一旦コンテナ内の tmp 領域にコピーして、それを entrypoint スクリプトでコピーしてから owner/permission を変更するというやり方で、リポジトリ管理で共有しやすいようにしてみた。entrypoint スクリプトは root 権限で実行されることも理解した。

volumes:
  - ./mongo/keyfile:/var/tmp/keyfile.orig
command:
  - mongod
  - --keyFile
  - /data/keyfile
  - --replSet
  - "myrs"
entrypoint:
  - bash
  - -c
  - |
    if [[ ! -f /data/keyfile ]]; then
      cp /var/tmp/keyfile.orig /data/keyfile
      chmod 400 /data/keyfile
      chown mongodb:mongodb /data/keyfile

    fi
    exec docker-entrypoint.sh $$@    

テックブログを読む会

昨日、西原さんに教えてもらった テックブログを読むイベント を探したら毎週月曜日に行われているようだった。早速 テックブログ一気読み選手権20231211杯 に参加した。HackMD で読んだメモを管理している。記事を選択して、読んで、所感をまとめて、他の人たちと共有する。ただそれだけのイベント。ちょうど30分で終わって、自分の勉強にもなったし、他の人の話しも聞いて参考になった。たった30分でも、なにもやらないよりずっとよい。1ヶ月ほど参加してやり方を学んだらチームにも展開してみようかと考えている。

23時に寝て2時に起きて4時半に起きて6時までゲームやって8時に起きた。朝からオフィスで発表資料を作ってた。

2023年ふりかえり

今年を振り返ろう！LT大会 に参加した。

昨日の夜に LT 資料を作ろうと思っていたものの、晩ご飯食べたら面倒になってそのまま家で休んでいた。朝からオフィスで作り始めたら徐々に興が乗ってきて想定した以上にちゃんと作ってしまった。やぎさんにレビューしてもらっていくつか気付きを得た。ちょうど レビューサービス あったら依頼したいなと思ったところだったのでレビューしてくれる人の存在に感謝した。この資料はまたなにか他の機会のイベントでも再利用しようと思う。カフーツさんの忘年会で発表してもよいかもしれない。

• 2023年ふりかえり

北海道から 西原さん という方が参加されていた。全国あちこちのコミュニティに参加して、そこに集う人たちの支援や盛り上げ、ひいては日本の IT コミュニティを活性化させて、世の中をよくしようといった取り組みをされている。これは私も共感するところで大半の人はコミュニティ活動に関心がない。それ自体は個人の好みで構わないのだけど、プログラミングを学びたいと考えているのに行動できない人たちというのが一定数いて、そういう人たちの受け皿として IT コミュニティで始めるのはよいことだと思う。西原さんはまさにそういう活動をされている。とても尊いことだと思う。

短時間にも関わらず、いろいろな話しをして私自身収穫もあったし、西原さんから学ぶことも多かった。企業のテックブログを読む会を毎週30分、社内外でやっていると話されていた。これは素晴らしいなと思ってすぐに反応した。歳のせいか、私は自分で勉強しなくなっていて、本も仕事も課題も積みまくりで、毎日どうしよう？と途方に暮れながら帰っておいしい晩ご飯を食べてゲームしている。そんな自分で勉強しない人向けにこういったコストなく、無理なく、続けられるイベントはありがたい。やり方を学ぶためにオンラインで参加してみようと思う。

• ブログを見つけて読んで感想書いてそれを肴に交流する会を30分でやりきっています

コミュニティ活動の価値というのは、多くの企業もコミュニティを盛り上げようとやっていることから明らかに大きな価値があるにも関わらず、その価値を十分に明文化できていない。私自身、コミュニティからたくさんのモノや影響を受けているにも関わらず、うまく明文化できていないところがある。課題管理の研究の延長上でコミュニティの価値にも追究していきたいと考えている。