Posts for: #Network

久しぶりにコードリーティングイベントに参加

久しぶりにコードリーティングイベントに参加

今日のバドミントン練習はメイビス2で壁当てを15分した。勉強会帰りで疲れていたせいか、夜遅くのせいか、あまりカラダが動かなかった。日付が変わってから 中学校体育館の12月予約 で4つ抽選申し込みをしていたが、すべて落選していた。2ヶ月続けてすべて落選したことからそうそう予約は取れないことがわかってきた。

昼間は昨日の続きで mongodb のトランザクション導入のマージリクエストをレビューしてもらって、テスト環境へデプロイして検証していた。id 連携のシステム間連携において意図した振る舞いにならなくてその調査をしていた。チーム勉強会で mongodb のトランザクション周りのいろいろをメンバーに共有した。17時前にお仕事を終えて定期歯科検診へ行ってきた。前回対応してくれたスタッフさんで「また少し痩せました?」と聞かれた。8月からだとほとんど変わっていないと思うが、今週は普段より多く運動できているのでその影響もあるのかもしれない。30分ほどですんなり終わった。

コードリーティング

歯医者を終えてから KOBE.go #7 - コードリーディング会 へ行ってきた。移転したハックバーへ行くのも初めて。三ノ宮駅から10分ほど歩いた場所の、こじんまりしたバーだった。10人程度入ったらいっぱいかな。おそらく集客や家賃などを考えたら妥当なサイズと立地なのだと推測する。いまは水-日の18-23時、月・火がお休みという営業時間らしい。私が着いたときはカウンターが埋まっていたのでテーブル席で発表を聞きながらコメントしたりしていた。私以外の参加者の大半は学生さん、みんな20代の方ばかりだったと思う。kyoto.go で発表したりしていたせいか、kobe.go のスタッフさんにも名前を覚えてもらえていた。若い人がコミュニティを運営しているのはよいことだと私は考えている。年寄りの役割としてなにかしらコンテンツを提供することで協力できればと思う。

コードリーティングはおくたにさんという方が実装している gomoqt という Media over QUIC (MOQ) のサーバー/クライアントを題材とした。京都大学の学生さんで学生起業しているのかな?音声配信サービスをやりたいから moq ライブラリを開発していると話されていて、プロトコルを勉強して自前でサーバー/クライアントのライブラリを実装しようとするの、すごいなと思って聞いていた。quic のライブラリを使ってサーバー/クライアントを実装しているようにみえた。ソケット (トランスポート層) より上のレイヤーを実装すればよいならそんなに難しくはない。

私が想定するコードリーティングのイベントではなかったものの、参加者は誰も moq プロトコルを知らないので moq の背景や現状、プロトコル仕様を共有するようなイベントになっていた。それはそれで私は知らないことばかりなのでへーと思いながら聞いていた。21時半頃にはイベントも終わり、イベント告知や雑談モードになっていって、若い人たちの中におっさんがいても迷惑かなと22時前には退出した。帰る前にワンドリンク (Go という名前の柑橘系カクテル) の料金として700円を支払う。個人的にお酒を飲みながらの勉強会はあまり好きではない。気分や雰囲気でぐだぐだになる印象があって学ぶときは学び、終わってから飲みに行って雑談するといった切り替えが私は好み。バーで勉強会をするという雰囲気もあまり馴染めない。単純に狭いし暗いし椅子よくないし作業に集中しにくいという所感かな。

ぱっとしない休日

9月に入ってしまった。8月は開発者の生活を思い出すための試行錯誤の月だった。よくもわるくもかな。

キャンセル料の支払い

この前の金曜日は しみん福祉スポーツセンター の体育館を借りてバドミントンを行う予定だった。木曜日は戻ってこれない可能性 があったし、前日の天気予報では金曜日の夕方が神戸に台風が来る予報になっていた。そこで木曜日の夜に参加者も少なかったしキャンセルすることに決めた。キャンセルは1週間前でないとできないため、これは自然災害だから仕方がないと体育館のキャンセル料金3,000円を支払うことにした。直接、しみん福祉スポーツセンターの窓口でないと支払いできない。窓口へ行って paypay で支払いしてきた。しみん福祉スポーツセンターの体育館を借りるのは値段が高いので参加者数が増えてから借りる運用を変えようと思う。

X-Forwarded-For ヘッダーの制御

先日の作業の続き 。本当は土曜日にやろうと思っていて、全然やる気がなくて、なにもやらないよりはちょっとでもやった方がよいかと、今日やり始めたら集中できて2-3時間で調査と対応を完了した。もともと構築しているリバースプロキシとしての nginx には次のヘッダーを扱う設定が追加されていた。

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $server_name;

追加で remote_addr を置き換える設定を入れてみれば、リバースプロキシ経由でリクエストを受ける go の http Request が参照する RemoteAddr の値も置き換わるのかな?と検証してみた。

set_real_ip_from 172.29.0.0/16;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
proxy_set_header REMOTE_ADDR $remote_addr;

結論としては RemoteAddr の値は置き換わらなかった。nginx の real_ip_header モジュールは nginx 環境における remote_addr の値を変更する設定であり、転送するときにパケットの値を置き換えるものではないようにみえる。そこで api サーバー側で X-Forwarded-For ヘッダーを参照するのが正しい対応方法だと理解できた。このヘッダーを参照することは一般的な用途に思えるので調べたら echo の IP Address のドキュメントにその設定方法やユーティリティの扱いなどが書いてあってすぐに参照できることもわかった。

X-Forwarded-For ヘッダーはクライアントが任意で偽装できる。デフォルトでは内部ネットワークから転送されたヘッダーの値のみを信頼するように設定されている。それが次の IPExtractor の設定になる。デフォルトの制約を変更することもできるが、コンテナで運用するとすべての通信はコンテナネットワークの gateway からリクエストされているようにみえるのでアクセス制御という側面ではこの設定そのものにあまり意味はない。

e := echo.New()
e.IPExtractor = echo.ExtractIPFromXFFHeader()

X-Forwarded-For ヘッダーの値を実際に参照するときは c.Request().RemoteAddr ではなく c.RealIP() を使う。api サーバーはこのぐらいの変更で実際のクライアントから転送されてきた ip アドレスを知ることができた。

wifi ルーターの規格調査

今日の運動は腹筋ローラー,腕立て,スクワット,ハンドグリップをした。今日も全般的に雨降りだったので筋トレをメインにした。統計を 運動の記録 にまとめる。オフィスで軽く 右股関節の改善体操 をした。

wifi ルーターの規格

引っ越しした機会に wifi ルーターを wifi 6 対応のバッファローの WSR-1500AX2L/N に変更した。wifi 6 の速度があれば十分だろうと手頃な価格帯 (6,280円) のモデルを購入した。

業者さんから光クロス対応ルーターを用意してほしいと言われていた。フレッツ光クロス対応ルーター をみると、どうやらこのモデルは違うようだ。光クロス対応ってなんのことを言っているのか理解できていなかった。おそらく 10GBASE-T のことだと思う。最近のネットワークは家庭でも 10Gbps になっているのか。WSR-1500AX2L/N のインターフェースは 1Gbps なので光クロス回線の帯域をフル活用できない。それでも 5GHz だと 200 Mbps 前後、2.4GHz でも 50 Mbps 前後の速度が出ていて私の用途なら十分に速い。とはいえ、ネットワークは速ければ速いほどいいから、またお金の余裕があるときに wifi ルーターを買い替えてもよいかなと思う。INTERNET / LAN 両方とも 10Gbps 対応ポートを備えたモデルは WXR18000BE10P/N になる。実勢価格は5-6万円とけっこう高い。1-2年先でもいいかな。

wifi ルーターのアクセスポイントの SSID やパスワード、管理画面へのパスワードを初期設定から変更してカスタマイズした。たまにネットワーク設定やらないといろいろ忘れてしまう。

ホットクックの無線設定

wifi ルーターのカスタマイズを完了したのでホットクックをインターネットに接続した。ホットクックが接続できる wifi のアクセスポイントは 2.4 GHz の WPA2 Personal になる。暗号方式は AES を選択する。ホットクックのために wifi ルーターの 2.4 GHz も有効にしないといけない。そして、ホットクックの wifi ルーターの接続設定がすごくわかりにくい。初めてやったときも苦労したけど、今回の再設定も苦労したので要項を書いておく。

  1. (ホットクック) 無線 LAN 接続設定を開く
  2. (ホットクック) 「アプリで接続」という状態にする
  3. (スマホアプリ) アプリ設定から機器を追加する
  4. (スマホアプリ) アプリ設定を進めて、スマホの wifi のアクセスポイントをホットクックの AP に接続させる
  5. (スマホ) ローカルネットワークの wifi ルーターに接続させる
  6. (ホットクック) 音声で接続できたことがわかる
  7. (スマホ) wifi のアクセスポイントをローカルネットワークの wifi ルーターに切り替える
  8. (スマホアプリ) アプリ設定の機器登録ができていることを確認する

一時的にホットクックを無線 LAN のアクセスポイントにするという手順が直感的にわかりにくい。本体から無線 LAN 接続設定を行う (wifi 接続のパスワード入力する) 方法がないから苦肉の策でこういう仕様になっているように思える。

迷惑をかけない死に方

居場所の雑談 と関連して、自分の死に方も少し意識するようになってきた。父が亡くなったとき はあまりショックを受けることはなかった。昔から父とは距離があったのと、病院で寝たきりの生活が5年もあったから心の準備ができていたのかもしれない。母とはちょいちょい電話したりもするし、実家に帰ったときはご飯を食べに行ったりもするし、一緒に田んぼ作業をしたり、父よりはずっと私にとって身近な存在であると言える。親が亡くなったときに大きなショックを受けた知人の話しをたまに聞く。母が亡くなると私も孤独感を感じるんやろか?と考えるときもある。

こういった記事をみかけるとついつい読んでしまう。読んでなにかが変わるわけでもないが、たまにショックを受けて辛くもなりつつ、避けられない未来を考えるきっかけになる。母は私が看取るとして自分は孤独死になるだろうからその対策を漠然を考えたりするときもある。カフーツさんでそういう話しをしていたときに はっぴーの家ろっけん というシェアハウスを教えてもらった。訳ありっぽい老若男女の大家族が一緒に住むといった暮らしをしている。これからの日本において孤独死する老人は増えていくだろうから、こういった取り組みやコミュニティの在り方はもっと一般化していくと推測される。

こういう取り組みを自分でやるかどうかは別として、私もいつかはお世話したりされたりの互助的なコミュニティに関わることになるのだろうと漠然と考えている。自分が死んだときにいくらか財産が残っていると仮定して、甥や姪に寄贈するという考え方もあるけど、こういった施設やコミュニティが長く続くよう寄付するというのもよいかもしれない。居場所の延長上で死に場所も一緒に考えていけるとよい。いまコミュニティやコワーキングについて研究していることがいずれ役に立つ気がする。

ガールズバンドクライ

おすすめされて 響け!ユーフォニアム に続いて ガールズバンドクライ というアニメを一気にみた。個人的にはこちらの方が私は楽しめた作品だった。思春期特有の葛藤や逡巡を表現していて、痛い感じの少女が成長していくような、王道の青春ストーリーになっている。ロックバンドと痛い感じの女の子たちがマッチしていて、ロックってそういう鬱屈した気持ちをストレートに吐き出すなにかと相性がよいのだなとも感じた。この作品をみていて私が感じたことの1つに、追い求めているときが一番楽しいという気持ちを思い起こさせてくれた。最近 いくつか目標を達成して燃え尽き になっていた。十分に休養をとったのでだいぶ回復してきたところでもある。

この作品は、声優がバンドをやるのではなく、バンドをやりたい人たちに声優をさせる というアプローチで作られているらしい。すでに楽曲はいくつもリリースされている。ちょうど運動するときの音楽を探していたところなのでしばらくガールズバンドクライの楽曲を聞きながらやってみようと思う。仁菜の歌う空の箱 (VOID) や運命の華 (I’m here) などが好み。

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

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

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

転居先のインターネット回線を申し込みした。コンシェルジュから 賃貸ねっと を紹介されて値段も安かったのでそれでいいやと決めた。いま 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 になったのでレビューするのも大変。基本的なロジックは問題なかったけれど、メンバーがしっかりレビューしてくれたおかげで細かいところをみていくと、いくつか修正点があった。感謝。レビューを終えて、マージして、テスト環境にデプロイして、一通り動いていることは確認した。ここからは運用レベルの検証に入っていく。週末も昨日もあまり寝てないのもあって、台風がきているし、今日はここで休むことにした。疲れたー。