眼科と眼鏡市場とメガネ選び

いつから (1ヶ月前か、2週間前か) 朝起きると右目の視界がぼやけるようになった。起きて身支度を整えたりして時間が経つうちに普通にみえるようになるので生活に支障はなかったものの、視界が一時的に悪化している状態に不安を感じていた。まぶたを痛めたのか、3ヶ月ほど前から右目をこすると痛みがあって右目を触らないようにもしていた。その後、まぶたの痛みは小さくなり自然治癒で治ってきたかな？と思い始めた頃に視界がぼやけるようになった。もしかしたらまぶたの痛みの延長で目の状態が悪くなっているのではないかと不安に感じていた。

「貧すれば鈍する」で神戸に引っ越してきてから眼科へ行ったことがないからどこへ行っていいかわからない。仕事にも支障がないからと放置していた。ようやく今日 菊地眼科 へ行くことができた。予約が不要だったので空いていれば受診しようと考え、実際に訪問して5-6人しか待ちがいなかったのでそのまま受診した。スタッフも親切丁寧で設備もよかったと思う。一通りの検査をして眼の病気はないとのこと。寝起きに視界がぼやけるのは眼の疲れからくるドライアイではないかとのこと。冬だと乾燥して起こりやすいらしい。2月は 本番切り替え が予定されていて、前月よりも長時間働いているし、本番開始のストレスやプレッシャーもあったように思える。いくつかの条件がたまたま重なった症状なのかもしれない。目薬を処方してもらったのでしばらく様子をみる。

眼科へ行ったついでにメガネを作るための視力検査も行った。但し、眼科で視力検査の処方をすると、その処方結果に従う強制力があり、メガネショップでの微調整やレンズ交換のサービスなどを受けられないとのこと。同じような視力検査をメガネショップで行った方がよいとアドバイスをもらった。視力は片目はどちらも 0.3 、両目で 0.7 ぐらいのとのこと。近視と乱視もあるとのこと。右目よりは気持ちだけ左目の方が視力がよい。目の前にモニターがあって仕事をする分には 0.3 という視力はちょうどよいらしい。これまで私がお仕事で困ることはなかった。しかし、車の運転に必要な視力の最低基準でもある。車に乗るときは眼鏡をした方がよいとアドバイスを受けた。

その後、近所の 眼鏡市場 さんへ行ってきた。眼科と同じような視力検査と微調整をして 1.0 のレンズを選択することにした。乱視を矯正する強い？レンズを選択すれば 1.2 まで視力は上がる。しかし、初めてのメガネだと眼に負担がかかってしんどいのではないかとのこと。別に視力をあげる理由もないので慣れることも考慮して 1.0 から始めるのがよいだろうという総合判断となった。余談だが、スタッフの方から私ぐらいの年齢で 0.3 からメガネをつけて 1.2 まで視力が回復するのはよい方だという。メガネをつければ誰でも視力が回復するというわけでもなく、メガネをつけても 0.7 程度といった状況もあるらしい。

フレームもよくわからなくてスタッフさんと相談して選んだ。バドミントンのときにも付けてみたいと話したらスポーツ向けのフレームがあって、値段も他と変わらず、たしかに装着感があってよかったのでスポーツ向けのフレームにした。i-ATHLETE (アイアスリート) IA-472 というモデルで、フレーム+レンズで 19,800 円 (税込)、ブルーライト対策レンズ が 3,300 円 (税込) とのことで、スマホやモニターをみる機会が多い生活をしているし、そのぐらいの値段なら付けておくことにした。合計で 23,100 円 (税込) になる。paypay で支払いすればクーポンを使って 10% はポイント還元された。

眼の健康のためにメガネを付けて過ごす方がよいのか、あまり付けない方がよいのかをスタッフへ尋ねた。はっきりとした答えではないが、メガネを付けることでいまの視力がどんどん悪くなるといったことはないとのこと。裸眼だと遠くがぼやけてみえないが、メガネを付けて遠くがみえる状態になったら、それを維持するように意識するとか、遠くを眺める機会をもつことそのものは眼の健康によいとのこと。運動するときや外へ出掛けるときにメガネを付けて遠くをみる意識付けをしてみようと思う。

メガネを付けて帰ってくるときに遠くの看板や文字がはっきりみえることに驚いた。20代の頃は 1.5 から 1.2 ぐらいの視力があったと思う。比較することで視力が大きく悪化していることに気付いた。

ai 談義の続き

昨日に続いて やぎさんと ai について雑談した。うちの会社の課題管理ビジネスの展望を根底から考え直す上で多くの人と話していきたい。

• github copoilot の評判

  • チャットがすごくよいとのこと

• 課題管理の文脈で ai と協業するための書く技術が大事になっていくのではないか

  • 人間は既存ドキュメントに書かれていることをちゃんと読まない
    • 既存ドキュメントを調べずに質問する人は一定数いる
      • 私もよく知らないプロジェクトなどだとそういう経験はあるかも？
  • 聞く相手として ai がいると助かる場面は容易に想像できる
    • 人間相手に次のことをすると、サポートコストを上げたり、相手を苛つかせる (ストレスを与える) ことにつながる懸念がある
      • 同じことを何度も聞く
      • 自分で調べずに丸投げで聞く
  • 課題管理は ai にインプットを与え続けるような役割になるかもしれない

• 文章を書けない人たちが組織にどのぐらいかの所感

  • 4象限マトリクスで考える
    • 書くスキルがあり、書く習慣がある
      • 2割ぐらい
    • 書くスキルがあり、書く習慣がない
      • 1割ぐらい
    • 書くスキルがなく、書く習慣がある
      • この割合はあまりいない
      • 一般論として書く習慣があれば書くスキルは上がっていく
    • 書くスキルがなく、書く習慣がない
      • 5割ぐらい
  • スキル／能力と習慣という分け方も分析に使えるかもしれない

• 分業制の弊害と ai の全体最適への可能性

  • 【解説】OpenAI発表[生成AIの進化5段階]とは？-未来がUtopiaかDystopiaかは"最終ステップ"にかかっている の記事ではレベル5で組織マネジメントに言及している
  • 現代の開発は分業制になっているため、部分最適はできるが、全体最適が難しい
    • 言われたことだけをやるような開発者は、自身のドメイン以外の分野などに関心をもたない場合がある
      • その結果として自身の職務に関係ない最適化や改善を行わない場合がある
    • 権限をもっていて改善を明示的に指示するマネージャー／リーダーが価値を発揮する
      • この全体最適の役割は人間よりも ai の方が知識をもつことで上手くなっていくのではないか
  • 開発環境の構築を本番構成しか用意していないあるプロジェクトの話題
    • 小さく起動、小さく改善、小さく検証ができる仕組みを先に作る必要がある
      • UNIX哲学 からの示唆
      • この視点に気付かない開発者へ誰がどのように示唆を与えるか？
    • アーキテクチャやインフラに関心がない開発者ならそうなる

雑談を休憩して、やぎさんの 将棋ウォーズ の対戦もみせてもらった。初段同士の対戦なのでどちらも一進一退の攻防で見どころがあった。持ち時間が10分で時間切れになったら負け。複雑な局面を相手に仕掛け、相手に考えさせて時間を使わせるという戦略があることを、実際の対戦をみせてもらってよくわかった。やぎさんが自分の打ち筋の考えを解説しながらうっていて、ゲーム実況をみているような感覚でおもしろかった。

やぎさんとは同年代なのでここ3ヶ月ほどの体調不良を相談してみた。平日の業務時間は普通にオフィスへ行って仕事できているが、それ以外の時間に調べものしたり本を読んだり日記を書いたりといったことが手につかなくなっていた。予定が入っているとこなすが、それもしんどいからなるべく予定を入れないようにもしていた。(健康な) 若い人に相談するのは難しいから同年代の友だちや知人がいると助かる。年齢による体調不良の可能性も高い。同じような経験があれば、相談して参考になることがあるかもしれないし、そうじゃなくても身近な話題として聞いてもらえるだけでも、自分の中に抱え込まず気分転換になる。話してみてずいぶんと気持ちが楽になった。心の中にある思考や感情などを外部に出す無意識の防衛機構のことを 思考の外在化 と呼ぶことを過去にも調べたことがある。過去の記事から改めて「書くこと」と「話すこと」の比較を読み直してみた。書くことだけでは得られない「気付き」はある。さらに今回は体調不良からの不安やストレスを軽減する目的で「話すこと」の方が役に立った。書くよりも話す方がずっとコストが低いからだと思う。書く意欲や余裕をなくしてしまって書けなくなっていた。日記を書くことさえできないしんどい状況でも、身近な人たちと話すことはできる。それによって、いま書ける状態を取り戻せつつある。「書くこと」と「話すこと」はどちらも大事。

ストレッチ

今日の開脚幅は開始前151cmで、ストレッチ後156cmだった。昨日ジョギングした後に軽くストレッチしたので少し数値はよかったように思う。トレーナーさんとメガネの話しをした。トレーナーさんは学生の頃から裸眼で 0.2 程度、普段はメガネをつけずに過ごしているが、車に乗るときだけメガネをつけるという。0.2 から下がるわけでもなく、そのぐらいの視力をずっと維持しているという。ちょうど私と同じぐらいの視力だったので視界がぼやける感覚やメガネを付ける生活のあれこれを尋ねたりした。トレーナーさんは夜間の運転が怖いと話されていた。私もたまに夜に車で実家へ帰ったりしていたものの、神戸市街や高速道路は街灯があるせいか、あまり夜に低視力を気にしたことはなかった。運転の話しをしていて、うちの母親は70歳を超えていて私よりもずっと視力が悪いはずだけど、毎日、車の運転をしていて大丈夫なんやろか？と心配になった。田舎は車がないと生活できない。いずれ私も車を運転できなくなることを想定して実家を離れる必要があるだろう。

実家へ帰って3年ぶりに高校の友だちと会うことになった。毎年大晦日に会ってご飯を食べて麻雀をやっていたのが、最近は葬儀があったりお正月に仕事があったりで集まりがなくなっていた。久しぶりに集まれそうと準備をしていたものの、直前に参加者の1人の身内に不幸があって4人集まることはできなかった。したがって3人になったので麻雀はやらずにお昼に集まって雑談して夜早めに解散した。

車を買ったのが2年前。3年前から友だちに会っていなかったので私が車を所有していることを知らなかった。11時に高校の友だちと待ち合わせて一緒に車で実家へ帰ることにした。1人で帰るよりも、誰か乗ってくれた方が話し相手になってくれるから同じ距離を運転していても到着するのが早く感じる。淡路島へ帰ってから、友だちの家に3人で集まってただひたすら雑談していた感じだった。3年ぶりに会ったというのもあって近況を話すネタもいろいろあった。その中でもやはり兵庫県知事の話題が一番盛り上がった。みんな兵庫県には住んでいるので背景をよく知っていてそれぞれの調べた情報や意見を交換して楽しめた。

私もちょうど年末に 百条委員会や定例会見をみてまとめた ところだった。その記事にもさいとうさんのコミュニケーションスキルに懸念があるように書いた。そして、私の友だちもそのことについては言及していた。詳細を忘れてしまったが、次の「ひょうご地域創生交付金」の廃止について話していたと思う。さいとうさんの前の知事の時代に作られた県から全市町を対象にした補助金で10億円程度の予算だった。これをいきなり廃止すると打ち出して、それについてさいとうさんは一切の説明をしなかったらしい。その友だちが言うには、大阪の維新でも改革するときに利権に対する喧々諤々の論争をした上で改革していったという。大阪の維新と比べても、さいとうさんは一切の説明も議論もなく改革しようとしたため、強い反発があり、結果的に「ひょうご地域創生交付金」を廃止はできず23-25年度は3億円の補助金となったらしい。

• 兵庫県の独自「交付金」、25年度まで年３億円で存続　政令・中核市など対象外

こういった急な改革を議論せずに独断で進めようとした結果、県議や自治体とのコミュニケーションがうまく取れていなかったのではないか？という背景が浮かび上がってきた。その友だちと話した後に「コミュニケーション」のキーワードで検索したらそれっぽい記事もいくつか出てきた。既得権益がどうこうというのもあるのだろうけれど、急過ぎる改革と説明すらしないという不遜な態度もあって反さいとうさんの陣営が大きくなっていったのではないかと考えられる。

• 尼崎市長、斎藤知事に苦言！県政混乱の本質的問題はコミュ力不足
• 兵庫県の斎藤前知事は、なぜ改革に反対する勢力の謀略に負けたのか？

前日の夜から法要のために実家へ帰っていた。前日は19時にお仕事を終え、お風呂に入って準備をして21時半には出発した。しばらく日記を書くことをお休みしていたから夜に帰る余裕をもてた。今日は夕方には神戸へ戻ってきて、夜はオフィス行ってお仕事のコードを書いていた。

三回忌

亡くなって1年後に行う法要を 一周忌 と呼び、2年後に行う法要を三回忌と呼ぶ。初めての人は勘違いしやすい。私も半年前まで勘違いしていた。

10時から住職に来ていただいてお経をあげていただく。住職が来られたらまずお茶を出す。お教を読み始めたら、回し焼香を参加者が順番にやっていく。15分ほど住職がお教を読んだ後に、参加者も一緒に般若心経を読む。これも15分ぐらいかな。だいたい20-30分程度でお経をあげるのは終わる。その後の住職の法話が始まる。このタイミングで新しいお茶とお茶菓子を用意しつつ、一緒にお布施とお膳料も添えて渡す。

今日の住職の法話は亡くなった人との関係性において自分を知る機会になるという発見について話された。住職の父親はうちの父親が亡くなった翌日に亡くなられた。当時、葬儀の打ち合わせのためにお寺へ伺った際に住職自身も葬儀の準備でバタバタしていると話されていた。そのときに住職の父親は厳しい方だったと伺ったことを覚えている。うちの父親は逆にほとんど子どもには怒ることはなかった。住職は自身の父親が亡くなって最近になってから、自分は父親に褒められたかったのだと、そのことにふと気付いたと話されていた。父親が亡くなってからの1年目は日々の生活に追われ、2年目になってからそのことをゆっくり考えられるようになったのだという。お釈迦様も自分を知るのは難しいといった説法をしているそうな。他人との関係性からふと自分を知るきっかけが訪れるという気付きについて話された。住職にとっては父親との関係性において2年目というタイミングがそうだったのだという。

3日前にお手伝い先の忘年会に出席した。5人で話していて、私以外は家庭をもっていて子どもがいて、そういった家族の話しをしている中、私は独身だから家族の話題にはついていけないし提供することもできない。もしかしたら周りに気を遣わせてしまっているかもしれないと、この卓に私がいて申し訳ないといった気持ちにもなった。懇親会や忘年会のような親睦を深めるための一般的な社交イベントに、プライベートに何も共通の話題がない私のような状況は向かないのだろうと思えた。とくに是非の話しではない。城崎温泉の開発合宿の参加者は独身者の方が多かったのでそのことに気付いていなかった。住職の法話を聞いていてそのときの自身の空虚さや違和感に気付いたことを思い出していた。

法話を終え、今回は卒塔婆が用意されていたのでお墓へもっていって供える。線香とライターを持っていってお墓で線香を3本たてる。お墓参りを終えたらそこで住職は帰られる。その後に参加者との法要後の食事へ行く。今回は身内だけだったので近所の回転寿司で簡単な食事で済ませた。12時過ぎには法要を終えた。

粗大ごみの処分

午後から実家の掃除をして粗大ゴミを整理していた。親戚からベッドをもらってきたようで、それを置くためのスペースを空けるために不要な家具を粗大ゴミとして捨てることにした。戸棚、ローテーブル、過去に使っていた古いベッドの残骸、扇風機、給湯ポットなどで軽トラックの荷台はいっぱいになった。いまベッドは2つあるのでこの離れに2人泊まれる。半年前に取り組んでいた実家の離れのコワーキングスペース化も一段落していて設備面では5人程度が作業するスペース分の机と椅子はある。あとはコンテンツを用意していく必要がある。思いつくキーワードを列挙していくと次になる。

• 農業体験
• 近所の温泉
• バドミントン

設備面で wifi のインターネット回線がないという最大の懸念が残っている。回線を引くと5千円/月はかかるので毎月のように誰か来るなら引いてもいいが、現状だと経費的にもったいないから躊躇している。もう少し寝かせて先送りする。

古本の処分

粗大ゴミの整理をしていて あかつき教育図書 出版の「昭和日本史」という図鑑のような本が全巻 (16巻) あった。故祖父が通販で買ったものらしい。離れに置いておいても読む人はいないし場所も取るので処分することに決めた。保存状態がよかったし、図鑑のようなものを捨てるのはもったいないと思い、古本屋さんへ持っていけば必要とする然るべきところで活用されたら嬉しいなと実家から神戸まで運んできた。淡路島よりも神戸の方が古本屋さんがたくさんあるから引き取ってもらえるだろうと考えた。花隈駅近くの 古書ノーボ さんに電話して帰りの車でそのまま運び込んだ。査定してもらって買取価格は全巻で500円だった。店主曰く「こういったセットものは価値そのものはあるのだが、全巻セットを家に置こうという人が少ないために買取価格は安くなってしまう。」と話されていた。価値はあるが需要はないという話し。まさに私が処分しようと思った動機そのものだったので納得感は高かった。

今日のバドミントン練習はエアシャトルでリフティングを10分、連続最大回数は322回だった。その後にショートサーブ30回、フットワーク10分の練習をした。リフティングは連続回数よりもラケットコントロールの質を求める練習に変えていく。昨日と同様、みなとのもり公園をジョギングで4週走った。fitbit によると 1.8km 走ったそうな。

プロジェクトマネージャーが手を動かすことの功罪

朝からお手伝い先の社内インフラサーバーが落ちていて待ち時間があったのでふと思い返してつらつら考えごとをしていた。

お客さんが選ばなければ、逡巡と葛藤の結果、最終的に私は品質を優先する

開発合宿の課題管理の雑談から引用

私はもっと仕組みを作るところに注力すべきだった。私自身がコンサル嫌いの、実務をやっている姿勢をみせてメンバーが参考にしてほしいという意識が強過ぎた。また開発は楽しいことから必要以上に手を動かし過ぎてコアな開発に入り過ぎたことで、自分がやらないと他のメンバーが担当しにくい体制になってしまった。「任せる」はずが「任される」ことになってしまった。バックエンドの品質は大事だから責任感もあった。もしかしたらお客さんが求める以上の過剰品質なモノづくりをしてしまったのかもしれない。そして、仕組みづくりの後はメンバーへ委譲すべきだった。いまメンバーへマネージャーを委譲しているが、マネージャーという業務はもともと得意でもなくこだわりもなかったがためにすんなりと委譲できた。

しかし、開発の方は得意分野、且つ好きであるために品質にこだわってしまう傾向があることを認識できた。そのことが裏目に出てしまった。これが自社プロダクトの開発ならばすべて自社の資産になるためにそれでもよかったかもしれないが、他社プロダクトでやってしまうと、自分の時間を必要以上に注ぎ込むことになってしまった。その結果、お客さんの信頼を得られてはいるものの、自社プロダクトの開発に着手できず、クロージングの時期が遅れて微妙な状況になってしまった。もしかしたら、お客さんもうちの会社との契約を終了できなくなってしまって困っているという考え方もできる。

rabbitmq の autoAck (noAck) の振る舞い

先週の続き 。id 連携のリクエストをし続けながら compose サービスを down させたときの振る舞いを検証する。理想的にはそれぞれのモジュールのサービスが graceful に振る舞って、それぞれの永続化する場所でデータが溜まってくれることを期待している。その1つがメッセージキューでもある。Persistence Configuration によると、rabbitmq のメッセージを永続化するには queue に対して durable の設定を行い、producer が送信するメッセージに対しても persistent の属性を付与すればよい。しかし、実際に検証してみると、サービスの再起動時にメッセージキューからメッセージが消失していることがわかった。consume メソッドに渡す仮引数に autoAck というパラメーターがある。コメントにもそれっぽいことが書いてある。

When autoAck (also known as noAck) is true, the server will acknowledge deliveries to this consumer prior to writing the delivery to the network. When autoAck is true, the consumer should not call Delivery.Ack. Automatically acknowledging deliveries means that some deliveries may get lost if the consumer is unable to process them after the server delivers them. See http://www.rabbitmq.com/confirms.html for more details.

ConsumeWithContext

autoAck という名前からメッセージを取得したら自動的にそのメッセージに対して ack を返すようなイメージで私は考えていた。しかし、どうやら consumer が subscribe して接続した時点で consume 扱いとなり、consumer がメッセージを実際に取得したかどうかに関係なく consumer の終了時にそのときに溜まっているすべてのメッセージが消失しているようにみえる。余談だが、rabbitmq のドキュメントにも noAck と autoAck という2つの用語が存在する。どうやらもともと noAck という名前だったのを autoAck という用語に変更したようにみえる。メッセージを永続化するには autoAck=false にしてメッセージに対する処理を完了した後に consumer が必ず ack を返すという実装にしないといけないことがわかった。このパラメーターは2年前から同じ設定だったので私がいま検証するまで誰もこの振る舞いに気付かなかったんやと驚いた。

部屋の掃除

19時に閉まる業務スーパーへ買いものへ行くために18時過ぎにお仕事を終えて、移動して買いものをして、炊飯開始して、ジョギングして、戻って晩ごはんを食べて、バドミントン練習をして、お風呂に入って、ストレッチして、なんとなくベッドに入って休もうとした。ここで22時半ぐらい。まったく眠れなくて寝室の掃除を始めたら、これが捗ってやる気が出てきて、部屋のレイアウト変更したりして少し片付けもできた。引っ越してからまったく進めていなかった部屋づくりが突発的に急に少しできた。これまでも時間がなかったわけではないが、まったくやる気がなくて手をつけられていなかった。それがなぜできたのかはわからないが、手をつけられていなかったことに手を入れられたことで心理的に楽になった気がした。明日も帰ったら少しだけ部屋づくりの作業をしようと思う。

出張で道具がないのでバドミントン練習はおやすみ。

始発の新幹線で東京へ。定例会議に出て、昨日の カバレッジ計測 の成果をメンバーに共有して、その後もバグ修正や結合テストのリファクタリングをしていた。夕方には疲労で眠くなってきて17時でお仕事を終えて、お気に入りの 中華料理屋さんの晩酌セット を食べて、ホテルに帰って3時間ほど寝てた。起きてから軽く散歩に外に出たぐらいでまたホテルに戻って寝てた。毎月の出張で生活のリズムが乱れる。食べものと生活の拠点がいつもと違うのがしんどくなってきた。

今日のバドミントン練習はエアシャトルでリフティングを40分した。連続最大回数は168回だった。いくつか練習場所を転々としながら最終的にはホームのビルの軒下に行き着いた。環境のよい場所を知ってしまうと、それよりも劣る環境で練習することに抵抗を感じてしまう。昼間なら風がなくて人通りの少ないところであればどこでもそう大差はないが、夜は証明と背景でシャトル視認性 が変わってくる。21時まではホームのビルで、21時以降はその隣のビルでといった定番の練習場所ができつつある。今日はなんとなく調子がよくなくて練習していて手応えや集中力を感じなかった。

午前中に結合テスト改善に関するドキュメントを書いて、お昼から rpm パッケージングのリファクタリングやって、夕方に午前中に書いたドキュメントを使いながらメンバーに結合テスト改善の要項について共有した。そして17時半にはお仕事終えて帰った。晩ご飯も外食してリフティング練習も早めに切り上げて帰った。ここ数日あまり睡眠時間を取れていなかったのもあり、疲れているかも？と21時過ぎから横になって寝ていた。

昨日おこなった調査 の成果もあって、いろいろ他の開発作業も進捗して、今日はいくつか小さい issue を fix できて1日の成果としては満足できる内容になった。それで夕方に洗濯したり、晩ご飯を作ったり、家事をやる余裕があったり、さらにオフィスへ戻って作業をしてから外出してくることもできた。ここ数日にはなかった充実した1日だったように実感した。いまの生活に満足できなかったりモチベーションが上がらなかったりする背景の1つとして、溜まっている残タスクへのストレスがある。このストレスを解消するのは残タスクを fix することがもっとも効果的である。

結論はやる気がなくてもやるしかない。少しずつでも問題を解決していくしかない。

古い文章だが、いまでも覚えていてたまに引用する Joel on Software の格言の1つに 射撃しつつ前進 がある。いま自分が置かれている状況はまさにこれに相当するものなので地道な積み重ねをしていくしかない。そういうときもあって人生はちょうどよいのだろうと思う。

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 アドレスを知ることができた。

前泊移動

親からの依頼 16時半移動の19時半から友だちと東京で飲み会予定になっていた。昨日リリース作業があったそうでお仕事の影響で行けないという話しになったので新幹線の移動時間も19時52分〜に変更しての前泊になった。スマートEX は新幹線の予約変更を直前までできる。こういう予定が曖昧なときに便利なのを実感した。朝にスーツケースを準備してオフィスに持ち込んで16時から移動できるような段取りは組んでいたものの、なんか16時から移動というのも違和感があったのでキャンセルになっていつも通りのスケジュールで1日を過ごせたことはよかったと思う。

城崎温泉のアテンド

親が親戚と一緒に城崎温泉へ行きたいというので11月の下旬に旅館の予約をとった。サイトで条件を入れて検索したら、きのいえ のすぐ前にあった 緑風閣 がヒットしたので (前を通って) 知っている旅館なのでここでいいなと4人一部屋で予約した。私が車で運転して連れていって案内したりすることになりそう。うちはもともと旅行したりする家族ではなかったし、親がどこかへ行きたいということもあまりないのでこういった機会はなるべく要望に応えるようにはしている。過去2回うちの会社の合宿として城崎温泉へ行った話しを親にしているうちに関心をもったようだ。別に狙った意図ではなかったが、親が楽しむ機会になるならそれはそれでよかったなと思える。

歯科検診

17時から歯科検診へ行ってきた。スタッフに「痩せてませんか？」と尋ねられて3ヶ月ぶりならそれほど変わらないんじゃないかと返したが、そのスタッフが私の担当をするのは2月以来だったらしく、それならかなり変わりましたと話していた。たまにしか行かないのに、首まわりが全然違うと言われて、半年前の体型を覚えているんやなと思ってこっちが驚いた。たまに会う人向けのお断りとして「癌ではありません」と説明しといた。

生活のリズムづくり

ここ1ヶ月ほど開発者へ戻るための取り組みをしてきた。昼間にお仕事でコードを書いて、晩ごはんを食べてから、夜にコードを書くのが習慣的になってきた。概ね1日の作業時間が10-12時間になってきている。夜に開発できている日はだいたい20-21時頃から24時頃までコードを書いている。夜は割り込みが入らないので集中できる。今日も晩ごはんを食べて22時前から翌2時半ぐらいまでコーディングしていた。ファイルのアップロード／ダウンロードを扱う汎用 api を実装した。

いまの開発フェーズでは 過去の残課題 が多い。それはこれまでの私のマネジメント不備でもあるし、知見を得たことでアーキテクチャの不備や再設計のリファクタリングができるようになった課題も多い。技術的負債が溜まっているとみなせる。いずれにしても、実運用を間近に控えて直せるところをできるだけ直しておきたい。当初は私が改善する issue が仕様変更になるためにプロジェクト全体のボトルネックになってしまっていた。なるべく初期の開発で ボトルネックを解消 してからもペースを落とすことなく、集中して開発作業を継続できている。スケジュールの前倒しとまではいかないが、後手にまわっている印象はなく迅速に対応できている。個人的にもよいリズムと集中力が出てきたと感じている。その視点からみると、いま開発に向いている集中力をこれまでは体脂肪コントロールや運動に費やしてきたこともわかる。だから短期間に大きな成果が出た。人の可処分時間は決まっている。継続的になにかに取り組むと1ヶ月も経てば実感できるぐらいの成果がでる。もしかしたら私がフルタイムの開発者として作業できるのはあと3ヶ月になるかもしれない。悔いの残らないよう、できるだけ集中して取り組もうと思う。

先週末に pr を送っていたから午前中にそのマージ作業をやって、他にもいくつか開発が順調に進捗したにもあって早めにお仕事を終えて自転車のパンク修理へ出掛けた。夕方から雨が降ったりやんだりで微妙な天候だったものの、大きく雨には降られなかったのでそれはそれでラッキーだった。

一番近い自転車屋さんへパンク修理にもっていくと、パッチ対応はしていなくてチューブ交換になってしまう。たまにしかないことではあるけど、チューブ交換で5,500円もかかる。ちょっと高い。他を探す時間もないから仕方ない。自転車を預けて1時間ほど待ち時間があり、その間にスーパーへ行って買いものして家に戻り、すぐにまた自転車屋さんに受け取りに行くといった感じで2時間ほどかかった。

軽く雨降りの中、傘をさして行ったり来たりしたのもあって疲れて夜のコーディングは行わずに早くに休んだ。