7時に寝て9時半に起きた。昨日は遅くまで起きてたのでこのまま寝たら寝坊する懸念が高かったからそのまま起きてて6時55分の新幹線に乗って移動中寝てた。祝日だったせいか、新幹線は空いてて快適だった。

もくもく会

出張もくもく会 を開催した。品川駅から飯田橋駅へのアクセスが予想外に悪くて30分ほどかかって10分ほど遅刻した。5人ほど部屋の前で待っていて悪いことした。午前中は8人参加していて、みんなそれぞれの課題をもってきて取り組んでいた。午後から1人来られた。参加者は全部で9名だった。参加者の属性も時代の変化を表していてデザイナーやプログラマーにジョブチェンジして勉強していますという参加者が数名おられた。私は svelte のチュートリアルをいくつかやっていた。あまり寝てなかったので15時頃は眠くてほとんど作業にならなかった。16時頃から眠気も覚めて本を読んでいた。17時30分まで借りていたが、17時過ぎには撤収して軽く飲みに行った。9名中7名が参加してくれていろんなお話が聞けて楽しかった。コロナ禍前の勉強会の雰囲気に戻ってきた。

会場は スペースアイエレガンス飯田橋 という貸し会議室を借りた。10時00分から17時30分まで7.5時間借りて税込7,425円。他の貸し会議室に比べると安い方に分類される。ワンルームのマンションの一室を貸し会議室にアレンジしたような部屋で築年数は感覚的に15年以上は経っているのではないか。古い。机に向かって座れる定員が10人。パイプ椅子が4つ置いてあって座れる定員は14名。部屋はやや窮屈で机に10人が向かって座るといっぱいいっぱい。3人掛けの机は間を空けて2人で座るのがよさそうにみえた。快適にもくもく会をするなら8人の定員が望ましい。トイレは普通。wifi の速度は200Mbps程度で十分に速かったし、8人接続していても安定していた。エアコンも普通かな。部屋が狭さに対してエアコンは有効で寒いということはなかった。

フリーランス、４０歳の壁

フリーランス、４０歳の壁 の後半を読んだ。

• 「第8章 都築響一 還暦を迎えても奔放なフリー人生。」
• 「第9章 フリーランスの上がりとしての創業社長。」

都築氏は1956年生まれて私よりも2周り近く上なのでさらに昔に活躍された方のようだ。 現場主義な方で実際に起こっている事実を観察して自分なりの解釈や判断でフリーランスとして活躍された方のようにみえる。本書に出てくるフリーランスの方々は私からみてあまりピンと来なかったのだけど、この方の生き方や考え方がもっとも私に近くて参考になった。

編集者と作家を兼ねるこういう仕事スタイルをとる人を、私は「編集家」と呼んでおり、自分自身の肩書きにも使っています。都築響一さんは、私の定義を完全に満たした「編集家」です。

やりたいことがあれば自分で試してみて試行錯誤しながらやっていく雰囲気を感じる。都築氏は仕事で大変なことはあったが、壁には当たったことはないという。ある歳を境に仕事が減ることもあったそうだけど、ネットが年齢差や対面でのお仕事を不要にしたという。

僕は、過去に仕事が途絶えることもありましたが、壁だとは思いませんでした。仕事がない時期にこそ、はじめて自分にとって大切なもの、必要でないものが見極められるんです。そのときは大変でも、後になってみたら、立ち止まって考える時期を持つことは大切かもしれません。

こういう考え方も私の好み。ピンチはチャンス。

「違いますね。（大手は）給料が良すぎるっていう、それだけが問題なんですよ。その若い社員編集者も、会社に不満があるのなら、辞めて自分の会社を作れば良いんです。でも、高い給料を捨ててまで自分の道を貫こうという気迫がない。僕もいまの出版界に不満はありますよ。だからこそいまの僕は、自分で直販の道を探して、メディアを作っているわけです。」

若い編集者が上司の愚痴を昔とは時代が違うとこぼしているのに対する答え。もともと会社に頼っていない人間だからこそこういう考え方ができる。私も不満があれば区切りのよいところで会社を辞めてきた人間なのでこういう姿勢も似ている。ググるとインタビュー記事をみかけたのでまた後で読んでみようと思う。

• 普遍、あるいは洗練について。

最後の章は著者が会社を作ったときの話し。最初の起業は大失敗したものの、なんやらかんやらでなんとかなってますといった雰囲気。著者は会社員はできなくても社長ならできるという。創業社長には発達障害だと思われる人がたくさんいるとも書いている。これは流石にバイアスが強過ぎると思う。会社を作ることは誰でもできるが、ある程度長く会社を存続できる人は少ないし、その続けられている人の割合に発達障害と思われる人はずっと少ないと思う。たまたまそういう属性の人が活躍すると有名になるだけで多くの創業社長は普通の人だと思う。一方で橘玲氏の本にもよく出てくる話しだが、日本は解雇規制がために中途採用の敷居がとても高いため、経歴がよくない人は年齢とともに転職がとても難しい。そんな経歴のよくない人でも会社は作れて、取引は法人を介して行われるので個人の経歴を隠蔽もしくはリセットできるという側面をもっている。だからフリーランスの上がりが創業社長なのではなく、経歴の悪い人が最後に働く手段が創業社長なのだと私は認識している。

期待した内容ではなかったものの、賛否も含めて示唆に富む本だったと思う。また余裕があれば書評をブログの記事として書こうと思う。

0時に寝て5時半に起きた。たぶん何度か起きたけど、久しぶりによく眠れた。ここ2-3日ほとんど寝てなかったせいかな。

お寺で予定調整

四十九日法要 の予定を立てないといけないのでお寺へ訪問した。淡路島では真言宗の宗派が多いらしい。うちもそう。明日から7日ごとに49日までの日程がある。7日ごとに住職にお経をあげていただく。告別式に初七日をしているので1月1日の分は済みとなっている。おそらく宗派や地域によって異なると思うが、このうち、重要なのは35日と49日だという。35日に行う だんご転がし という風習は淡路島独自のものらしい。

• 命日: 12月26日0時34分
• 7日: 1月1日
• 14日: 1月8日
• 21日: 1月15日
• 28日: 1月22日
• 35日: 1月29日
• 42日: 2月5日
• 49日: 2月12日

35日は家族のみで、49日は親戚を呼び一般的な法要を行う。その他の日は親族の選択でよいという。省略可能な背景として昨今は多忙な人が多く、亡くなった人よりも生きている人の方が大事という考えからだという。母は信心深いのでなるべくお経をあげてほしいというので7日ごとに住職を招くのではないかと思う。私は35日と49日の2つに参加する。日曜日なのでお仕事に影響を与えず都合がよい。これから法事や親戚の用事などで実家に帰る機会が増えていくことになる見通し。

建具屋さん

家の玄関の鍵の調子が悪い。たまにうまくまわらないときがあって、壊れる前兆みたいな状態。ホームセンターに鍵交換してもらえないかを聞いたら作業員が徳島県にいるそうで、来てくれるかどうかすら分からないという。近所の建具屋さんに行ったら快くみてくれるという。田舎の家の困ったことは近所の建具屋さんやと理解できた。建具屋さんの主人が丁寧に応対してくれた。困ったときはここに来ようと安心できた。初めて行ったお店の、接客態度はほんと大事だと思う。その丁寧さや論理の明快さをみて私はリピーターになることを決める。論理が多少通じなくても親切だったらそれでもよい。そういう意味では人のよさや人間力は論理よりも大事なのかもしれない。翌日9時から家に来てくれて調査した上で交換用の鍵を発注してくれるという。16時に訪問して状況を説明して翌日すぐ来てくれるという対応が気に入った。

オンライン忘年会

はらさんが投稿していたのをみかけた。gather に集まってオンライン忘年会に参加した。私は葬儀があったので直近の近況報告や忘年会の予定を2つほどキャンセルしていた。葬儀も無事に終わって一息ついていたのでちょうどよかった。最大8人が参加していて、私は知らない方が多かったものの、ざっくばらんにお話しして19時から始めて22時半ぐらいまでやっていた気がする。よしださんもおられた。よしださんの近況は私の置かれた状況とも類似していて、私自身、よしださんの生活をモデルケースの1つとして参考にしている。コロナが働き方や生活スタイルに大きな変革をもたらした。3年前には想像もしなかった世の中の変化があるなぁとみんなで話したりしていた。

0時に寝て何度か起きて7時に起きた。だいぶ眠れるようになってきた。

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

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。来年やりたいことというテーマだった。来年の抱負というほど堅苦しいわけではないが、それぞれの参加者別にやりたいことをわーっと話すようなイベントだった。私は課題管理について軽く話し始めたらいとうさんが深堀りしてくれて、参加者からも共感を得られてそれなりに盛り上がった。自分が参加したイベントの録画を見返すことを私は滅多にしないのだけど、今回は話した内容を整理するために見返した。

課題管理という分野の体系化、ならびにプラクティスの整備をしたい

ざっくり話した内容はこんな感じ。

• 課題管理を追求していくにはメンバーに強制・指示できるだけの権限が必要となる

  • ボトムアップで課題管理を実践するのは難しい
  • 課題管理の実践のために人の運用を変えないといけない場面が出てくる

• 私は it 業界のプロダクト開発における課題管理のノウハウしかない

  • 複数の組織・チームで働く過程で課題管理ができていない、または課題管理システムを使いこなせていない開発者やチームがたくさんあることを知ったのが背景になる

• 本質的には、課題管理自体は業界・業種を問わない分野だと思うので広く応用できるプラクティスとして体系化したい

• 課題管理とは、ハウツー本を読んだり、ツールを導入すれば解決する類のものではない

  • それぞれの目的のためにメンバーが日々の業務において運用していく必要がある
  • メンバー全員が運用しなかったら効果もその度合いに応じて減っていく
    • 権限が必要というのは、やらない人に対してある程度はやってもらう必要があるから

• 課題管理をうまくやろうとすると、組織論や組織の文化、マネジメントの分野とも密接に紐づく

• 課題管理と密接な分野の1つに情報共有がある

  • 情報の一元管理は組織において重要なのに疎かになっている組織やチームは多い
    • 一元管理できると情報共有のためのコミュニケーションコストを削減できる
    • このためには組織レベルで使うツールや情報共有のやり方を統一しないといけない
      • 自分の好きなツールを使って自由に情報共有するといったものをいくらか制限する必要がある

• 課題管理において重要なことの1つに文章を書けない人たちが一定数いることを受け入れないといけない

  • 情報共有の文脈で言えば、テキスト化は検索できるという大きなメリットをもたらす
  • 一定数の文章を書けない人たちをどう対応するかは難しい課題の1つ
    • 文章を書くための練習をすればよいのではないか
      • 新人やキャリアの浅いメンバーには有効となる
    • 文章を書かなくても情報共有できる手段と組み合わせるとよいのではないか
      • it 業界ではスクラム開発という開発方法論が流行っている
        • 大雑把に言えば、対話を重視して会議をたくさん設けることで情報共有を密にする開発方法論と言える
          • 文章を書けない人であっても話せない人はほぼいない
          • 対話を促されれば話すことで情報共有できる
        • デメリットとしてはコミュニケーションコストがとても高い
          • このコミュニケーションコストは開発における生産性とトレードオフになる

• 課題管理において重要なことのもう1つに文章を読めない人たちも一定数いる

  • 日本人の1/3は日本語が読めない？PIAAC (国際成人力調査) の調査結果
  • 文章を書いてメンバーに読んでおいてと伝えても1/3は理解できていない可能性を示唆している
    • 情報共有において文章を書いても伝わっていない可能性を考慮して対策する必要がある

• 仮に情報共有できていない状態でメンバー「わからない」と言えることはすごく重要になる

  • この文脈で心理的安全性が重要になる
  • 「わからない」と声をあげてくれることで文章や伝え方を改善していける可能性がある

• 実は一昔前と比べて、いまの方がメンバー間の情報共有を疎遠にしている背景がある

  • いまは情報共有にクラウドサービスを使う組織が増えている
    • 基本的にクラウドサービスはユーザー単位/従量制で課金される
      • あまりサービスを使わないユーザーアカウントを減らすことでコストダウンできるインセンティブが働く
        • 情報共有という視点からコストダウンしてはいけないコストを削ってしまっている
          • 例) 課題管理システムのアカウントは開発者しかもっていないとか
    • 中小規模の会社ほどクラウドサービスを多用するのでこの傾向がある
  • 昔はオンプレで社内システムを管理していたため、システムのユーザーを減らすインセンティブはなかった
    • 要否に関わらず、社員は全員アカウントをもっていることが当たり前だった
  • 念のため、クラウドサービスのアカウントをメンバー全員がもつことは目的ではない
    • アカウントをもった上でそのメンバーがそのサービスを使うように運用を変えていく必要がある
    • システム投資とメンバーの運用を変える取り組みがセットでないとうまくいかない

• コワーキングスペースは課題が持ち込まれるところではある

  • 課題管理のプラクティスが応用できるなら使いたい
  • 課題をどう整理して、優先順位を付け、情報共有していくかは難しい
  • 様々なメンバー、様々なツール、様々な課題を同じツールで一元管理することは非常に難しい
    • どうやって情報の一元管理をするかはコワーキングスペースの運営において難しい課題でもある
      • 複数のサービスを連携するサービスなどを使って一元管理する方法もある
    • 海外ではコワーキングスペース向けの sns も含めたプラットフォームサービスなども出始めている
      • 日本ではまだまだあまりシステム化されておらず、導入もされていないのではないか

• コワーキングの分野では女性がとても活躍しているように、いとうさんから見えている

  • 今後もこの分野を盛り上げていくのは女性ではないか？
    • 男性は変なプライドが邪魔して行動力を抑制してしまうところがあるのではないか
    • 女性は損得勘定から行動力を発揮しているのではないか
      • 男性の方が感情的な動機でコワーキングをしているようにみえる？

• コワーキングに課題管理の理論やシステム化はあってよいのではないかと、いとうさんはみている

22時に寝て0時に起きて、4時5時と起きて7時に起きた。昨日の夜ぐらいからずっと頭痛がする。体調悪い。

ストレッチ

今日の開脚幅は開始前153cmで、ストレッチ後157cmだった。先週とほぼ変わらず疲弊と疲労が抜けきっていない。右太もも周りの張りや違和感が依然として強い。腰も自覚症状はなかったもののストレッチを受けていると張りが強いことに気付いた。トレーナーさんからも調子悪そうみたいなコメントもあった。田んぼ・出張を経てのオフィス移転から引っ越しに伴う行政手続きと、この3週間のバタバタした負荷が残っているみたい。土日もずっと作業を継続しているのもよくないのかもしれない。とはいえ、お仕事も引っ越しの行政手続きも一段落はついたので徐々に復調していくはず。

もくもく会 & 忘年会

ストレッチを終えたら普段はオフィスで調べものをしているところ、頭痛でしんどいから家に帰って寝てた。そして14時から 【三宮.dev】今年を〆るもくもく会 に参加した。2022年7月頃に移転したばかりの中央区の区役所の上に 中央区文化センター がある。そこで開催されて初めて施設に入った。新設した施設なのできれいで設備も充実していてよさそうにみえた。うちのオフィスからも近い。うちの会社にお客さんが来ることはないのだけど、大人数の打ち合わせにも使えそう。

オフィスへ行かなかった日は day off というタグで記録している。オフィスへ行ったからといった必ずしもお仕事しているわけではないけれど、役員は考えること・為すことすべてが事業に関連するという考えからオフィスへ行く・行かないという基準で day off という概念を私の中で切り替えている。家で寝てても頭痛はおさまらなかったものの、気合を入れてもくもく会へ行って日記を書いたり調べものをしたりしていた。17時にもくもく会が終わって忘年会へ続く。頭痛はまだ残っていたものの、お昼よりは少しましになった。忘年会も休もうかどうか迷ったんだけど、普段来られない方々もいたのでせっかくの機会だと思って、本気出して忘年会へ行ってきた。体調悪いからお酒は控えた。忘年会でいろいろな話しを聞けたので行って楽しかった。

体調悪いから2次会は控えて家に帰ってきてそのまますぐ寝てた。

1時に寝て何度か起きて7時に起きた。1-2時頃に吐き気がして苦しむ割に後半はなにもなかったかのように眠れることがある。

openapi-generator の調査

毎週の勉強会に向けて最新の openapi-generator を使って出力した go client のコードを読んだりしていた。openapi-generator を簡単に試すためのチュートリアルのようなものとして、過去にリポジトリに整理しておいた。このリポジトリを使うとコード生成とドキュメント生成の両方を試してスキーマがあることのメリットを体験できるようになっている。

• https://github.com/kazamori/try-openapi-generator-cli

chatgpt で遊ぶ

【おあそぶ会】GPT3と遊ぶ に参加した。gpt3 についてちょうさんが調べたメモにも目を通して参考になった。

• 20221215【おあそぶ会】GPT3と遊ぶ

ちょうさんの gpt3 の説明を聞きながら chatgpt で葬送のフリーレンについてチャットしてた。今日の成果はこれかな。

1時に寝て2時に起きて吐き気に苦しんで6時に起きた。後半はよく眠れた気がする。

フロントエンドの技術選定の調査

はらさんにお願いした フロントエンド勉強会 の内容を踏まえて技術選定を行う。次の3つを候補とした。

• react
• svelte
• solid

客観的な指標で3つの技術を調査して比較した時点で solid はうちのチームにはあわないと候補から除外することにした。なので react vs svelte の一騎討ちとなる。なにか理由がない (デファクトスタンダード) なら react だし、うちのチームにとって有効だと判断できる項目があるなら svelte になる。ここで next.js と svelte kit でちょっとコードを書いてみて自分なりの感触も探ろうと考えている。

• Svelte vs React: Which framework to learn in 2023?

インフレ勉強会

エンジニアのためのインフレ研究会 #1 に参加した。お仕事の調べものをしながら聞いてた。私はもう常連で前々から同じような話を聞いているものの、発表者の資料も説明もわかりやすいものだったと思う。

0時に寝て夜中に吐き気がして2回ほど起きて3時と5時に起きて8時に起きた。なかなか苦しい寝方をした。

ヤフートラベルと一休.comのシステム統合

アーカイブ公開されたらみようと思いつつ忘れてたので見返した。

雑なめも。また機をみて見返すこともあるかも。

• バックエンドは完全に一休側に寄せるという大きな意志決定を2016年に行った
  • この意志決定はフロントエンド統合にも大きな影響を与えた
  • ふじもんさんの意志決定がよかった？
• 今日の話しはマルチブランドデザインシステム統合がメイン
  • 開発者が50-60人程度で半年ぐらいで launch できた
  • nuxt/vuejs で開発している
  • スタイルは tailwindcss を使っている
  • 実は launch した後にこのシステムが必要だとわかった
    • 開発者とデザイナー間の細かい意思疎通が困難
    • 外部からデザインシステムに詳しい人にも来てもらっていろんな議論をした
    • ガイドラインを言語化するところから始め、最終的にソースコードの共有ができるようになった
  • 終わってからデザインシステムそのものは重要ではないと気付いた
    • この過程で開発者とデザイナー間のどのように共通化するか、あるいはしないかと議論を繰り返し行ったことが重要だったと当事者がインタビューで語っていた
    • デザインシステムの開発を通じてデザインの共通認識をもてたことがよかった
• 波及効果
  • 同じソースコードから少し異なる体験の開発のノウハウができた
  • ふるさと納税に特化した宿泊予約サイトを作った
• 統合は終わりではない、lauch したところが始まり
  • 統合後にいろいろな施策をすることで課題がみえてくることがある
• 全国旅行支援は1つの開発で2つの体験をつくることができた
• Q. デザイナーと開発者はわりと仲が悪いのでは？価値観や考え方が異なるのですり合わせるのは難しいのでは？
  • 過去の一休でも起きていた
  • 一休のチームはデザイナーと PM と開発者で構成されている
    • このチームが一緒に働いていてチームでなるべく意志決定している
    • 普段から一緒に働いていると仲が悪いということはなかった
    • とはいえ、仕事のプロセスが異なるので課題はあった
      • 地道に丁寧にすり合わせを行った
      • 外部から講師を読んで中立的な立場でワークショップを何度も行った
  • デザイナーと開発者を別の組織にしているとコミュニケーションの壁ができてしまうかもしれない

go の学び直し

テストの学び直し に引き続き、Gopher塾 #2 - Goらしいコードの書き方 - DAY 1 に参加した。

テストの次のプログラミングの話しだったので内容そのものは難しくはなかったけど、改めて重要な項目を選抜しているのだと考えると学びはあったと思う。参考になったことをいくつか覚えている範囲でまとめる。名前の付け方について感覚的に理解していたし、実際に私はそうしているけど、コードレビューしていて自然になっていないコードを指摘する機会も多いので一定の習熟を要するのかもしれない。いま毎週勉強会をやっていて私が講師として話している。ネタがなくなってきたり大変になったきたら準備の少ないコードリーディング会もやってみたいと思った。

• google Go Style
• derrors.Wrap
• 名前に文脈を与えるという概念
  • 相対的な名前をつける
• 準備の少ないコードリーディング会
  • お題（読むパッケージ）を決める
  • 選んだお題に期待することを当日話す
  • 時間を決めてみんなでそれぞれ読む（20分とか）
  • 読みながらSlackのスレッドにメモをしていく
  • 残りの時間で気になったところを議論する
  • 自分が気づけなかった点を知ることができる

0時に寝て何度か起きて7時に起きた。金曜日は普通の週でも疲れているが、今週はハードだったからさらにバテバテ。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。オフィス移転に伴う諸々を雑談したり、おもには夕方から講師をしてもらうフロントエンド勉強会の最終確認のようなことをしていた。

フロントエンド勉強会

私がマネージャーとなって今月決めないといけない大きな意志決定の1つにフロントエンドの技術選定がある。とはいえ、私はフロントエンドに関して素人なのでなにかしら取っ掛かりがほしい。その参考の1つとして、はらさんにお願いして技術選定というテーマでフロントエンド勉強会を開催してもらった。感謝。いまお手伝い先では私が毎週チーム勉強会を行っている。これも1ヶ月以上続けている。そろそろ定着しつつあってチーム外からも毎週数人が参加してくれるようになってきた。勉強会という開発文化の取り組みとしてもちょうどよいように思ったのでお手伝い先も巻き込んで講師だけ社外の人が務める勉強会となった。結果は15人以上参加してくれて質疑応答も盛り上がってよかったと思う。

State of JS アンケート (ここは翻訳されたサイト) という、主にはフロントエンドの開発者の調査結果がある。これはフロントエンドの開発者のみのアンケートなので偏りはあるだろうというのも考慮しつつ、最近のトレンドを理解する上でよさそうに思えた。React をデファクトスタンダードとして、対抗する候補に Svelte のみを私は考えていたが、もう1つ Solid を加えてもよいのではないかとアンケート調査をみていて思うようになった。

私にとってもっとも参考になった技術選定の考え方としてリニューアルを前提にフロントエンドを作るというもの。技術選定で難しいことの1つは、いま流行っている技術が未来もそうかどうか誰にもわからない。未来に人気がなくなって保守されなくなって開発中止となり、フロントエンドの作り直しを強いられることを避けたいという心理や懸念は一般的だと思われる。その懸念を逆転の発想をもって、例えば、作ってから3年経ったら既存のフロントエンドはすべて捨てて作り直すと決めておけば多くの悩みは解消される。こういう言い方をすると多くのフロントエンド開発者は怒るかもしれない。私にとってはプロダクトのコアはバックエンドであってフロントエンドはそうではない。だからフロントエンドはそのときの流行りの技術で動けば何でもよいという考え方は納得感が高い。

創立記念日

今日が会社の創立記念日。無事に3周年を迎えた。いつか創立記念日をお休みにしたいが、未だそのときではない。

2年目は大きな失敗も経験して経営やキャリアの両方で反省する機会にもなった。その過程でうちの会社はなにをやるのかという基本方針とプロダクトの種のようなものができた。3年目はプロダクト開発の前段階としての実証実験のようなことを実際のお客さんの業務を通じて行っている。しかもそれがいま2社目。会社を作ったときに最初の10年間のステージを3つに分けた。そしてそのステージにおけるフェーズ1の終わりが近づいていて、目標としていたことも達成の見込みがたっている。うまくいけば来年の中旬以降から実証実験の結果を踏まえたプロダクト開発に移っていけるかもしれない。そうなればフェーズ2に移行する。起業してから3年経ってもありがたいことにお仕事はあるし応援してくれる人たちもいる。周りの人たちに恵まれていて感謝することも多い。過去の自分がやってきたことに自信をもっているからその人脈も継続できているし、少しずつ新しい関係性を作っていくことにも注意を払っている。あと何年働けるだろうかと考えることもしばしばある。もうそんなに長くないこともわかっているので悔いのないよう挑戦していきたい。

0時に寝て3時に起きて6時半に起きた。前日あまり寝てなかったから普段よりよく眠れた。

rabbitmq の認証

たまたまなのだけど、前のお仕事でも rabbitmq を使っていて、いまのお仕事でも rabbitmq を使っている。私の中では kafka のエコシステムに感銘を受けたので私が技術選定してよいなら kafka を使っていきたいところだけど、rabbitmq も人気があってすごいなと思う。インフラを触っていて rabbitmq の認証をしていないことに気付いた。rabbitmq の docker image を使うとデフォルトで guest/guest のユーザーが作られる。

If you wish to change the default username and password of guest / guest, you can do so with the RABBITMQ_DEFAULT_USER and RABBITMQ_DEFAULT_PASS environmental variables. These variables were available previously in the docker-specific entrypoint shell script but are now available in RabbitMQ directly.

おそらくメッセージのやり取りを通信するときも何も指定しなかったら guest ユーザーとして扱っているのかな？通信するときの RabbitMQ URI Specification によると、amqp://user:pass@host:10000/vhost のような、昔ながらの uri にユーザー／パスワードを埋め込むような認証になる。このやり方だと uri 自体が credentials になってしまって運用の使い勝手が悪くなってしまうものの、アプリケーションの変更は必要ないというメリットもある。おそらく歴史的に認証は後付けで追加されたのかな？ともかく実際の運用だとユーザー／パスワードでアクセス制御を行うだろうと想定されるので気付いたタイミングで開発環境の docker image の設定と uri の変更を行った。

時事ネタの気軽な雑談会

【おはなし会】CEXだって安全にできるもん に参加した。ちょうさんは fin-py のイベントで何度か発表を聞いたことがある。データサイエンス系のお仕事をされているのかな？ftx 事件 をうけて ethereum の創始者である vitalik buterin 氏がブログに投稿したアルゴリズムの解説をされていた。

• Having a safe CEX: proof of solvency and beyond

取引所の不正を防ぐための仕組みとして、それぞれの口座の残高を公開しなくても merkle tree とハッシュ関数をうまく使って、取引所が実際に管理している残高とユーザーの残高が一致しているかをチェックできるような、そんなアルゴリズムだったと思う。ちゃんとブログの記事を読んでないけど、ちょうさんの解説を聞く分にはアルゴリズムはそう難しくないように思えた。そんなすごい仕組みじゃなくて、簡易的に大きな計算コストもなく全体の残高があっていることのおおよそのチェックはできますよといったもの。

イベントが始まる前にちょうさんが大学の研究室にいた頃、研究室へ行くと同僚がいて気軽に新しい技術の話しができたけど、社会人になるとそういう機会が減ってしまったという。時事ネタを気軽に雑談できるイベントがあればという話しをされていて私も共感できた。

0時に寝て6時前に起きた。昨日は夜にサッカーの試合をみながら寝た。早朝から田んぼ作業やって、慌てて戻ってイベント行って、バテバテで夕方はやや熱が出て寝込んでた。

玉ねぎを植える準備

昨日の続き。6時から田んぼへ行ける状態ではあったけど、まだ外が暗かったので7時から始めることに。畝を軽く耕して草をひき、苗を植えるための筋を作って、玉ねぎの苗を植えていく。途中から近所の手伝ってくれている方も参加して3人で作業をしていた。玉ねぎの苗を引く人、苗植えのために畝を耕す人、玉ねぎの苗を植えていく人といった役割分担。お昼休憩を含めて私は13時半まで手伝って神戸へ戻ることに。

草をひいたり玉ねぎの苗を植えたりするのに中腰で立ったり座ったりを繰り返す。筋トレに例えるとスクワット運動を何度も繰り返しているのに近い。太ももが筋肉痛になった。

ホームパーティー

13時50分に実家を出て15時頃に三ノ宮に戻る。ガソリンを満タンにしてレンタカーを返すのに10分ほどかかった。高速道路を降りて近くのガソリンスタンドへ行くルートを開拓しないといけない。一旦家に戻ってから三ノ宮.dev のホームパーティーイベントがあるというので行ってきた。13時からやっていたが、私は実家に戻ってたので16時前ぐらいから参加した。どういうイベントかまったく理解してなかった。いつもとは違う場所を借りてもくもく会みたいなのをやるのかと考えていたら普通にゲームしたり雑談したりするイベントだった。だからホームパーティーという名前なのかと行ってみて理解した。LienSpace という部屋貸しのレンタルスペースを借りて行われた。普通にマンションの一室を借りるような感じ。 3000円/時で4時間借りてたみたい。私が行ってから軽く雑談して人生ゲームやってそれでお開きになった。

23時に寝て2時に起きて気分悪くて寝付けずにだらだらしながら気付いたら5時になっていた。その後いつの間にか寝て8時に起きた。

go の学び直し

Gopher塾 #1 - Testing - DAY 3 に参加した。

マネージャーとして go 開発のマネジメントをしているため、メンバーの開発者よりは知識やスキルが高くないとコードレビューや適切な指示ができない。2018年ぐらいまで go 開発をしていたが、その後はずっと java 開発をしていたため、最近の go 開発の話題はあまり把握していない。毎週チーム勉強会 (いまのところ、go 開発の話題) をやっていると、チーム外からも開発者が参加してくれるようになった。チーム外からの開発者が go 開発するときの参考にもなるよう、マネージャーのお仕事の付加価値として、組織全体へ go 開発の知識やスキルを提供できればと考えながら働いている。

今回はテストについて話題で7割ぐらいは知っている知識ではあったが、3割ぐらいは最近の話題や静的解析の知見からの深い洞察を話されていてとても参考になった。知っている知識でも幅広いテストの話題の中で厳選されたコンテンツになるのだろうから本質的に大事なことや最初に学ぶべき優先事項を知ることもできた。私がメンバーに教えるときのコンテンツの参考として役に立つ。まったく知らなかった話題としては、txtar というテキストをアーカイブしたフォーマットをファイルシステムとして扱えるようにした txtarfs や、1.18 から追加された fuzzing というテストの入力値を自動生成する機能が追加されたこと。あと groovy でいうところの power assert に近い機能を提供するライブラリとして google/go-cmp をいまはテストに使うらしい。たまたま Go Test Comments を読んでいたら go-cmp は go の開発チームが保守していて go のバージョンに依らずほとんどの比較の要件にあうツールのように説明されていて利用を推奨している。