Posts for: #Network

引っ越しの準備を少しずつ始める

今日の運動は腹筋ローラー,背筋,縄跳び(両足跳),散歩,ハンドグリップ,ダンベルをした。統計を 運動の記録 にまとめる。

インターネット回線の申し込み

転居先のインターネット回線を申し込みした。コンシェルジュから 賃貸ねっと を紹介されて値段も安かったのでそれでいいやと決めた。いま iijmio のモバイルとひかり回線をセット割で契約している。社宅に引っ越ししたら、携帯電話は法人契約でインターネット回線は個人契約に変更する。どうせセット割できないのでどこでもいいやという所感。家で使うインターネットは映画やアニメをみるぐらいだから 1 Gbps もあれば十分やと思う。マンションのネット回線は光クロス対応らしく 10 Gbps の速度が出るのかな?ひとまず月々の料金が高くなるなら 1 Gbps で十分ですとは伝えた。さらに光クロス対応 wifi ルーターを買えと言われて、調べたらバッファロー WiFi ルーターが一番いいらしく、Wi-Fi 6 対応のエントリーモデルを選択した。光クロス対応って単純に速度の速いルーターのことであってる?全然いまのネットワークの規格やハードウェアについていけていない。引っ越しやってそういった設備をアップデートとして学ぶことが多い。定期的に移動することも大事。 

みなとのもりの運動

前回の所感 。昨日は足を休めて少しよくなったので今日はがんばろうと意気込んで行ったものの、人が多くてよい場所が見当たらなくて、少し狭い場所をとって縄跳びを始めたものの、そこにフライングディスクの アルティメット / Ultimate の練習をしているチームが寄せてきて、距離が近くて危なくて縄跳びやりにくくなった。おそらく大学のサークルの練習だったのではないかと思う。すぐ隣で走り回っているのに嫌気がさして集中力を欠いてしまった。心が弱い。

駐車場散策

いま住んでいるところの駐車場の解約申請を管理人さんに手渡した。転居先に駐車場そのものはあるものの、いまは満車でそこを借りることはできない。近所の駐車場を借りる必要がある。あらかじめ google map で付近の駐車場を探してあった。運動を終えた後に歩いていって、候補の駐車場がそれぞれどんな雰囲気かをみてきた。私の要件はこんなところ。管理人がいるような駐車場だと0時から朝7時までは閉鎖されてしまう。

  • 屋内で雨風を防げる
  • 24時間出し入れできる
  • 車庫はなるべく広い方がよい

2つ候補があって実際に現地でみて確認した。善は急げでよい方に帰ってきてすぐ申し込みした。免許、車検証、保険の写しなど、必要な書類をオンラインでアップロードした。行政手続きに慣れたせいか、この手の書類をいくつか提出しないといけない手続きを苦に思わず手早くできるようになった。書類も整理して保管してあるから探すことなく30分ほどで申し込みを終えた。

小さい会社の採用は難しい

1時頃に寝て2時半に起きて7時半に起きた。昨日は飲み歩いたのもあって寝不足気味で体調よくなかった。これも歳なんやろな。

今日の運動はレッグレイズ(椅子),スクワット,背筋,散歩をした。統計を 運動の記録 にまとめる。

社内版テックブログを読む会の3回目

新しい取り組みの3回目。前回の所感はここ

3回目なのでメンバーも慣れてうまくイベントをこなしていた。普段はオンラインでやっているけど、今日はオフラインで初めてやってみた。やはりオフラインの方が話しやすい。私はずっと svelte を「すべるて」と呼んできたのだけど、実はこれは「すべると」と発音するらしいと初めて知った。

今日は営業社員さんがこのチャンネルをみつけて参加してくれた。別に技術に特化しなくてもよいのでこういった他部署や他業種の人たちとも一緒にやれるのがこのイベントのよいところの1つでもある。営業さんらしく次の記事を共有してくれた。

web 制作会社でいい感じに売上が増えてきて、コロナ禍になったときにリモートワークならオフィスの制約なく社員を増やせると気付いて、急採用して社員を増やした結果、経費があがって利益率が悪化して、結果的に会社がうまくまわらなくなって改革したという話しみたい。社員を増やしたら会社の各種 kpi が悪化したというのがおもしろいところ。要は社員数が増えるとそれだけ受注や利益を多くあげないといけないが、組織の体制が出来ていないと右肩上がりにはならなかったという。取引の業績は悪くなっていないのに社員数が増えた分で会社の業績は悪化してしまった。会社の採用って本当に難しいと思う。うちの会社はいつになったら社員を雇用できるのだろうか。

ホテル付近を散歩

格闘家に学ぶ体脂肪コントロール 本に週に200分は有酸素運動をしろと書いてあって、1日あたり30分程度だという。散歩をするのがもっとも簡単でいいだろうと、大崎駅周辺のホテル近辺を散策して歩いた。ちょうど30分ほど歩いた。

今日は ダイワロイネットホテル東京大崎 に泊まっている。私は大崎という場所を気に入っていて、駅から直結でいけるこのホテルもよい。ビジネスホテルとしてはやや割高だけど、うまいこと安い時期が探して何度か泊まっている。部屋は広いし、お風呂も広いし、立地もよい。周りの飲食店も良さげなお店がたくさんあるのに混雑していない。

唯一イケてないのが wifi の遅さ。昨日の夜は全然つながらなくて、途中からスマホのテザリングに切り替えた。朝使っていると400Mbps程度の速度は出ている。おそらくネットワークの設計や dns サーバーのパフォーマンスなどが悪いのだと推測する。大きいホテルだからお客さんが何十人か同時に接続すると一気にパフォーマンスを悪化させているのだと思う。同時接続を考慮したネットワークの分割、ボトルネックの排除をやっていかないといけない。

年明けからコーポレート業務いろいろ

23時に寝て4時半頃に起きてそのまま6時半までだらだらして起きた。早寝早起き。

今日の筋トレは腹筋:20x1,腕立て:15x1,スクワット20x1をした。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。内容が多くて1時間超えた。

  • 電子帳簿保存法対応の事務処理規定の共有
    • まだ始まったばかりで税理士さんの温度感も低い
    • 事務処理規定が省令に沿っているかどうかの判断はプロセス監査で行われる
    • 電子帳簿保存法には規定されていないため、事務処理規定の妥当性の検証は行われない
  • 融資を受ける構想作り
    • 日本政策金融公庫のみで検討していたが、融資実績を作りたいなら信用金庫も加えた方がよい
    • 借金のメンタリティ、担当者との折衝や審査など余裕のあるときに経験を積んでおくことはよいように思えた
  • ファイナンシャルプランナーさんとのやり取り
    • 会社の経費で役員のための保険に入ろうと考えている
    • 個人の保険控除は8万円らしい
  • ローカル複業化プロジェクトの考察
    • IT コミュニティに老人や子どもたちは入りにくい。農業なら老若男女誰でも入れる気がする
    • 農業や地元の特産品を切り口にコワーキング (コミュニティ) で街の人たちと田舎の人たちをつなげるのはすごいことだと思う (関係人口の創出)
    • 地元の有力者と仲良くなると、行政の口利きもしてくれて活動しやすくなる

はらさんが よりひろいフロントエンド を始めたそうでその話しも聞いていた。個人のブログサイトにするのか、複数人で記事を共有するサイトにするのかもまだ曖昧だという。Contentful + Next.js + Cloudflare Pages という構成らしい。Contentful というツールを私が知らなかったのでまた時間のあるときに調べてみようと思う。

母が一人暮らしをしていて体調もよくないことから要介護状態になるリスクがそこそこあると考えている。最悪の場合、会社を休眠させてしばらく介護をするかもしれない。はらさんが仰るには休眠はよいアイディアだという。会社員に例えると退職した日の帰り道を想像するとよいと話されていたのだけど、私は過去の記憶があまりないというのもあるが、これまで6回も退職してきたのに退職日を特別に思ったことはあまりない。退職日と他の日に大きな違いはなくて、次のお仕事の準備や調査をしていることが私は多かったと思う。それでも退職にあわせて有休を1-2ヶ月とってゆっくり過ごしていたことには変わりない。私もそういう、メリハリのある働き方が好きだ。

smtp 接続のタイムアウト

たまたまメンバーが誤った設定で smtp サーバーに接続したときにタイムアウトするまで5分ほどかかるという現象を発見した。タイムアウトの設定をせずに接続しようとするからそんなことが起きるのかな?と考えて smtp クライアントのタイムアウト設定を調べてみると net.DialTimeout を使えばよいという。

多めに見積もって30秒のタイムアウトを設定して接続するようにして再度メンバーに再現検証してもらったら直っていないという。接続そのものは出来ていたのだ。ソースを読んでみると、smtp クライアントを生成するときに 220 というレスポンスを読むことがわかる。誤った接続設定でもコネクションは確立するが、レスポンスが返ってこなくて待ち状態になっていた。

func NewClient(conn net.Conn, host string) (*Client, error) {
	text := textproto.NewConn(conn)
	_, _, err := text.ReadResponse(220)
	if err != nil {
		text.Close()
		return nil, err
	}
	c := &Client{Text: text, conn: conn, serverName: host, localName: "localhost"}
	_, c.tls = conn.(*tls.Conn)
	return c, nil
}

調べてみると Conn インターフェースにデッドラインを設定する API が提供されている。注意事項としては接続した後にデッドラインをリセットしないといけない。

デッドラインとは、I/O操作がブロックされずに失敗する絶対時間のことである。デッドラインは、ReadやWriteを呼び出した直後のI/Oだけでなく、将来の保留中の I/O すべてに適用される。デッドラインを超過した後は、未来にデッドラインを設定することで、接続をリフレッシュすることができる。

デッドラインを超えた場合、ReadやWrite、その他のI/Oメソッドの呼び出しは、os.ErrDeadlineExceeded をラップしたエラーを返します。これは、errors.Is(err, os.ErrDeadlineExceeded)を使用してテストすることができます。errorのTimeoutメソッドはtrueを返しますが、期限を超過していなくてもTimeoutメソッドがtrueを返すエラーが他にもあることに注意してください。

アイドルタイムアウトは、ReadまたはWrite呼び出しに成功した後、デッドラインを繰り返し延長することで実装できる。tの値が0であれば、I/O操作はタイムアウトしない。

https://pkg.go.dev/net#Conn

次のように SetReadDeadline() を使ってタイムアウトを5分から30秒に短縮できた。

func (s *Clinet) connectWithReadDeadline(conn net.Conn) (*smtp.Client, error) {
	if err := conn.SetReadDeadline(time.Now().Add(dialTimeout)); err != nil {
		return nil, fmt.Errorf("failed to set read deadline: %w", err)
	}
	c, err := smtp.NewClient(conn, s.config.Host)
	if err != nil {
		return nil, fmt.Errorf("failed to connect to the smtp server: %w", err)
	}
	// clear read deadline
	if err := conn.SetReadDeadline(time.Time{}); err != nil {
		return nil, fmt.Errorf("failed to reset read deadline: %w", err)
	}
	return c, nil
}

MBTI 性格診断とか

2時過ぎに寝て6時半に起きて7時半に起きた。夜に相棒の元旦スペシャルをみていて、最後の方でニュースに切り替わって、その後、相棒の別の再放送?がまた始まるみたいな変な番組編成になっていた。起きてから神棚にお供えをしたり親戚を迎える準備をしていた。

今日の筋トレは腹筋:10x1,腕立て:10x1,スクワット10x1のように毎日書いていけば1ヶ月ぐらいは継続できるのではないか?

親戚とお昼ご飯

毎年2日は親戚がやってきてお昼ご飯を食べる。昨年は訃報でやらなかったので2年ぶり。今年は離れのスペースにダイニングテーブルを2つ入れた。この形態でやるのは初めて。鍋にすき焼きをつくり、あとお寿司とお刺身を7人で食べた。このぐらいの人数でご飯を食べるのはとくに問題なさそう。ご飯を食べたりするなら電子レンジもあった方が便利だと気付いた。11時から準備して12時頃から食べ始めて14時前ぐらいで解散。お年玉をあげたり、親戚の姪や甥の話しを聞いたりしていた。

この春から働き始める姪が言うには MBTI 性格診断 というのが流行っていて、就職活動で適正診断の1つとしてやるようなものになる。なぜかそれが一般にも流行っていて、若い人だとこのタイプをインスタのプロフィールに書いてあったりもするらしい。試しにやってみたら私は 建築家 INTJ-A タイプだった。タイプが16個あるので複数人でやったらタイプがバラけて盛り上がるのかもしれない。今度の開発合宿でもネタの1つにみんなにやってもらってもよいかもしれない。

iphone のテザリングの自動切断

iphone を wifi ルーター代わりにテザリングをしていると気付かないときに切断していることがある。調べてみると、通信がないと約90秒で自動切断するという仕様になっているらしい。これはテザリング接続のアクセスポイントの電波も停止してしまっていることから、iphone の設定を開いてインターネット共有の on/off をしないといけないという面倒さがある。

この振る舞いはバッテリーを節約したいデバイス側と通信帯域を節約したいキャリア側の思惑が一致するせいか、ユーザー設定でこの振る舞いをカスタマイズすることはできないようにみえる。

なにかしら通信していれば自動切断はしない仕様にみえるので ping コマンドで icmp パケットを定期的に (次の例では60秒ごと) に送るといったことをしていれば切断はされないようにみえる。

> ping -i 60 www.yahoo.co.jp

開発者ならすぐワークアラウンドを思いつくが、一般ユーザー向けに iphone のテザリングが自動切断されない接続アプリのようなものを作ってあげると一般ユーザーにウケるんじゃないかと考えたりもした。

おいしい 🦀 を食べに行く

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

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

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

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 のワークスペースをオープンしておかないといけないという用途はなかなか面倒だ。私が逆の立場でもそう思う。どうにか普段使っているワークスペースから、必要なときだけ連携できるような仕組みがないだろうか?

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

標準ライブラリに XOAUTH2 の実装がない

0時に寝て3時に起きて5時ぐらいまでネットで遊んでて6時半に起きた。昨日の夜に洗濯しようと思って忘れていたので朝から洗濯した。

隔週の雑談

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

  • 税理士さんとの打ち合わせのふりかえり
  • 昔お手伝いした会社の開発体制の話
  • 新しいチーム勉強会 の導入

3人の税理士さんと打ち合わせしてみて最終的に顧問契約をお願いする方を決めた。話してみてやり取りした雰囲気だと、その税理士さんもスキルやこちらの要件対応については全く問題なさそうに思えた。あとは報酬とうちの会社の規模などを考慮して選択した。

昔お手伝いした会社で2年経ってちょっと相談にのってほしいという打ち合わせをした。私がいた2年前と開発体制はまったく変わってなくて、未だにテックリードがほぼ1人で開発している状況らしい。私が辞めてから以降も何人かは開発者が入っては辞めを繰り返しているのだと推測する。私も2度とその開発者と一緒に働きたくないと思うぐらいには信頼してなくて、開発者が引く手あまたな世の中の状況において、人間として信頼されないリーダーって致命的なんだなということを改めて実感した。おそらくテックリードを追放しない限り、あの開発体制 (と言ってもほぼ独り開発) は何も変わらないのだろうと思う。

oauth 2.0 で認証して google の smtp サーバーを使う

昨日の続き

リフレッシュトークンを使って取得したアクセストークンで smtp の AUTH コマンドで XOAUTH2 で認証すればよい。仕様は次のドキュメントに書いてある。

なぜか go の標準ライブラリの net/smtp には Plain と CRAM-MD5 の2つしか実装されていない。AUTH コマンドの実装は smtp.Auth インターフェースで定義されている。

type Auth interface {
	Start(server *ServerInfo) (proto string, toServer []byte, err error)
	Next(fromServer []byte, more bool) (toServer []byte, err error)
}

正常系の雑な実装だとこんな感じ。

type oauth2 struct {
	user        string
	tokenType   string
	accessToken string
}

func (o *oauth2) Start(server *smtp.ServerInfo) (string, []byte, error) {
	if !server.TLS {
		return "", nil, fmt.Errorf("need tls")
	}
	resp := []byte("user=" + o.user "\001auth=" + o.tokenType  + " " + o.accessToken + "\001\001")
	return "XOAUTH2", resp, nil
}

func (o *oauth2) Next(fromServer []byte, more bool) ([]byte, error) {
	if more {
		return nil, errors.New("unexpected server challenge")
	}
	return nil, nil
}

ググるとサンプルコードを実装している人たちがちらほらいるので、そのうち標準ライブラリに誰か実装してくれると思う。

go 本体に pr を送るチャンスでもあるけど、Contribution Guide を少し眺めて大変そうと思って、いまそこまでのモチベーションないなって感じ。

xoauth2 という smtp の認証

0時に寝て何度か起きて6時に起きた。昨日、凡人が天才に挑むという状況で、キングダムの 蒙驁 将軍が廉頗に挑むみたいな状況を思い出して見返していた。史実では蒙驁が魏を攻めて東郡を置いたというのは事実だが、廉頗と戦ったという記録はなく、おそらくは蒙驁と廉頗に因縁があって雪辱戦としたというのはキングダムの創作だろうと推測される。

oauth 2.0 で認証して google の smtp サーバーを使う

google さんの smtp.gmail.com の smtp サーバーを使ってメールを送信したい。

2019年にパスワード認証は廃止するので oauth 2.0 へ移行してくださいといった、最初のアナウンスが行われて、もうできないかと思ったら2024年9月30日に完全廃止するのかな?まだパスワード認証は動くかもしれない。一方で oauth 2.0 へ移行しないといけないのでその調査をメンバーにしてもらっていた。結局、途中からは私も本気になって調べていた。

oauth 2.0 で認証してアクセストークンとリフレッシュトークンを取得するためのサンプルコードとして OAuth2DotPyRunThrough が用意されている。このトークンを取得するときに callback の url にユーザーが明示的にアクセスして同意する必要がある。ここで得たアクセストークンは1時間で有効期限がきれる。しかし、リフレッシュトークンはユーザーが revoke しない限りは永続的に使えるそうで、このリフレッシュトークンを使って必要なときにアクセストークンを取得するというのが google さんの oauth 2.0 のアプリケーションの運用になるみたい。つまりリフレッシュトークンをアプリケーション側で管理することでアクセストークンは何度でも取得できる。

OAuth 2.0 Mechanism によると、取得したアクセストークンを使って XOAUTH2 という smtp の認証方式で認証すれば smtp サーバーに対して smtp でメールを送信できる。gmail 以外でメールをやり取りする機会がなくなって数年たつ。smtp の仕組みとか、まったく忘れてしまって関心もない。たったこれだけなんだけど、右往左往してあちこち調べることになった。ややこしいのは google のクラウド api 経由でメールを送ることもできて、そのやり方と混同するとまったく違う方向に行ってしまう。そこだけ注意。

週明けから疲労困憊

4時に寝て7時に起きた。遅くまでコードを書いていたわけではないけど、眠れなかったのとお腹空いて夜にもぐもぐ夜食を食べていたせいかもしれない。たいてい月曜日は元気いっぱいなのに今日はバテバテだった。

wifi 復旧

金曜日からコワーキングスペースの wifi が不通 になっていた。午前中に業者がフロアの機器室の扉 (施錠されている) を開けて作業していた。週末に復旧できなかったのはシンプルに業者との保守契約に休日対応オプションが入っていなかったのかもしれない。運悪く連休に発生したために約3日間停止していた wifi が11時過ぎにようやく復旧した。フロアにまったく人影がなくて、みんなお盆休みなのかもしれない。

エージェントアプリケーション開発

昨日の続き 。朝からマージリクエストを作ってメンバーにレビューしてもらう。1000行程度の diff になったのでレビューするのも大変。基本的なロジックは問題なかったけれど、メンバーがしっかりレビューしてくれたおかげで細かいところをみていくと、いくつか修正点があった。感謝。レビューを終えて、マージして、テスト環境にデプロイして、一通り動いていることは確認した。ここからは運用レベルの検証に入っていく。週末も昨日もあまり寝てないのもあって、台風がきているし、今日はここで休むことにした。疲れたー。

go-ldap の syncrepl 機能のレビュー対応

1時に寝て何度か起きて7時に起きた。今週もよく働いたからバテバテ。

ストレッチ

これまでも慢性的に右足全般は悪かったのだけれども、今日は左足の張りがある (痛い) ところと右足の張りがある (痛い) ところが全然違うことに気付いた。トレーナーさんによるとさらに今日はいつもより上半身の腕も硬かったという話しだった。これから1ヶ月か、1ヶ月半ほどは開発の佳境で忙しくなる (座っている時間が長くなる) ので体調がよくなることはないと思う。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。普段通りなのでこの調子なら問題ない。

syncrepl のレビュー対応

先日のレビュー対応 の修正。通信プロトコルの処理を実装するには想定したパケット (byte 列) をデコードしないといけない。そのために誤っているとすぐに panic する。開発しているときは既存の処理の振る舞いと競合してあちこちで panic してデバッグが容易ではなかった。そこで既存処理とは分割して先ずは実装した。その後、プロトコルの仕様と対応するパケットを理解してしまえば、どこを直せばよいか把握できているので既存の処理と共存させることはとくに難しくなかった。私の先入観であちこち変更しないといけないのでは?と思い込んでしまっていたのをレビューアの指摘で気付くことができた。感謝。

これでレビュー対応を終えた。pr を送ってから2週間放置されていた。そこでレビューしてくれないかとお願いしたら2人のメンテナーがすぐにレビューしてくれた。これは 非同期検索 でのやり取りを経て私の信頼があがっていたためと思われる。この機能はお仕事の開発にも使う。ちょうどいま開発の佳境に際して花を添えるよいタイミングと言える。

進捗報告の資料作り

気付いたら来週は出張の週になる。月例報告のための資料を作っていないことに今日気付いて慌てて資料を作った。いまは開発の佳境の時期なので、開発方法論に新しいことを試しているわけでもないし、この1ヶ月のやったことの進捗を報告するだけ。内容は固まっていて資料を作るのはそんなに大変ではない。理想的なスケジュールだと9月上旬で開発完了を目指していたが、それは無理そうだと判断した。その次のイテレーションで完了できるように目指す。さらに追加でバッファのイテレーションももう1つある (と私が勝手に思っている) 。2つイテレーションを伸ばすと開発は1ヶ月の遅延となる。このぐらいのブレは私の中では許容範囲だけれども、一般の会社だと認められるのかどうか、開発マネジメントの機微によって分かれるのかもしれない。

なにもしないうちに一週間が過ぎた

2時に寝て何度か起きて6時に起きた。今週はゼロ時前後までオフィスで作業していることが多かったのであまり寝ていないが、月曜日にお休みをとった効果は抜群でほとんど疲労感はない。たまに休むことも大事なのかもしれない。

温湿度計

先日 暑さ対策委員会 を立ち上げて、まずは計測からだとエンペックスの温湿度計を購入したものが今日届いたので計測してみた。

11時頃は32℃、12時を超えると30℃過ぎぐらいに落ち着いた。夜になると28℃ぐらいまで下がった。ちなみにエアコンの温度設定は23℃となっている。午前中が一番暑いことに気付く。その理由は日当たりのよい部屋なので午前中は陽が窓から差し込むために窓付近があたためられるのだと推測する。幸いなのは湿度が40-50%と低いためにサーキュレーターで風を浴びているとなんとか暑さをしのげるところ。これで湿度が高い日はもうバテてお仕事とかできるんやろか?という気もする。

フロアの窓より遠いもっとも内側の区画は26℃になっている。エアコン設定の基本が25℃なので妥当な数値だし、普通に涼しい。私が感覚的に暑い、暑いと言っていたのが、私の感覚の問題ではなく、運営会社にクレームしても理解を得られるのではないかと思う。また週末か来週あたりに電話して相談してみようと思う。もしかしたらなにかしら対策を検討していてくれているかもしれない。

iijmio ギガプランの変更

先月の実家リモートワーク で普通にお仕事すると1GiB/日ぐらいは使うことに気付いた。2GiB プランだと全然足りないことに気付いたので 5GiB プランに変更した。これなら月に1週間ほど帰ってもお仕事できそう。

go-ldap の syncrepl 対応

2時に寝て2回ぐらい起きて6時半に起きた。お休みとったからいろいろ余裕がないけれど、体力だけはある。

syncrepl 機能の実装

go-ldap の非同期検索 の続き。persistent search という用語 も理解して、満を持して openldap の syncrepl 対応に臨んでいた。syncrepl を用いた persistent search というのは、簡単に言えばメッセージキューで言うところの pubsub のコンシューマーに相当する。その通信のテストやデバッグをしているときに非同期検索のバグもみつけた。余計なことをして返って複雑なバグを混入したなと反省しながら修正の pr を送った。

go-ldap の ldap 通信の処理や設計を理解するのに2日、rfc-4533 を読みながら Control に関するプロトコル実装に1日、テストやデバッグ、その他の調査や設計に2日ぐらい、次の pr を作るのに1週間 (平日5日) ほどは工数を割いた。

ローカル環境で単体レベルの動作は問題ないと思う。あとは私が知らない ldap プロトコルの振る舞いや単体レベルで検証できていない通信、実際の運用レベルの syncrepl の状態やエラーなどに耐えられるかどうかといったところだと思う。おそらく rfc を読みながらプロトコルの一部を私が実装したのは初めてかもしれない。もうサーバーサイドやバックエンドの領域で (スキルの多寡はあれども) 私が作れないものはそうないだろうという自信をもっている。実際に rfc で提案されたプロトコルを実装して、テストして、ちゃんと動いて、そういう日々がすごく楽しくて嬉しかった。根拠のなかった自信を確認できた。またレビューに時間かかるかな?マージのためのやり取りや修正に2週間から1ヶ月ぐらいを見込む。