0時に寝て何度か起きて6時に起きた。夜にストレッチを受けて寝たせいか、わりとよく眠れた。お仕事はコードレビューを中心に、既存のよくないところをリファクタリングして品質や堅牢性を高めることをしていた。

税理士さんと契約についての打ち合わせ

税理士さん探し の続き。3人の税理士さんと打ち合わせをして、その中で1人の税理士さんを選定した。ようやく、うちの会社も税理士さんに税務をお願いできるようになった。最初の打ち合わせを30分ほど行った。うちは会計システムに freee を使っているので freee の操作ができることを要件に探した。freee には税理士さんをアドバイザーとして招待する仕組みがあって、それを使って登録すると税理士さんがうちの会社の会計データを読み書きできるようになるという。まずはその登録作業を行った。他にも過去の決算書と決算申告のデータを共有したり、うちの会社の特徴や課題管理のやり方なども情報共有した。課題管理にも関心をもってくれたのでうちの会社の jira にも招待して、できれば、税理士さんもうちの会社の会計作業については jira で課題管理してくれると嬉しい。それは難しいかもだけど。

税理士さんが言うには、税理士会が情報共有のツールとして dropbox を推奨しているらしい。ファイルを情報共有するために dropbox のフォルダ共有してくれると助かるという。うちは google workspace を使っているので必然的に google drive が望ましいのだけど、それは税理士さんにあわせて dropbox にした。私の感覚だと、dropbox よりは google の方がセキュリティもサービスも信頼できてよいのだけど、そこは税理士会の慣習に従うことにした。

税理士さんは社内では slack を、お客さん向けには chatwork を使っているという。私は chatwork 使ったことがなかったのでこの機会に使うことにしてみた。これは税理士さん側から私を招待してもらって使えるようにした。どうやらフリープランで使ってみるみたい。chatwork にもフリープランあったんやと知った。

• 利用プランの変更

契約についてどうしましょう？と相談したところ、どっちでもよいと言う。税理士さんの守秘義務は法律で定められていて、これに違反すると懲戒処分に加えて、刑事罰もうけるような、強力なものらしい。したがって、税理士さんが契約書を企業と交わさなくても税務には問題がないらしい。一方で顧問契約を1年は継続してほしいといったときに期間を契約書に明記して契約するといったケースもあるらしい。先方がいらないと言っていたのでひとまず契約書なしで進めることにしてみる。

• 税理士の守秘義務

23時に寝て何度か起きて6時半に起きた。

田んぼ

7時からトラクターで田んぼを耕す。昨日の夜、普通に雨が降っていたので今日は田んぼ無理かなと諦めつつ、朝起きたら雨もあがっていて、田んぼもそれほど水浸しになってなかったので予定通りで耕作できた。昨日、刈った草を焼いてあったのでスペースが空いたところをトラクターで耕していく。全体のうちの半分ぐらいを耕した。玉ねぎとか、なにか野菜をまた植えるらしい。

トラクターは大きな機械なので田んぼの隅などはうまく耕せないし、畝を作るときの縦と横の相反する畝などは作れない。畝を作る目的の1つに排水がある。雨が降ったときに水が田んぼから流れていくように道を作らないといけない。トラクターで大まかに作った後に鍬で調整していく。私はこの鍬仕事が苦手でいつも親にやってもらうのだけど、30分だけ (これが限界) 手伝うようにしている。中央の水を抜くための谷を開通させるところだけ30分ほど作業した。

ストレッチ

お昼過ぎに帰ってきてそのまま休んでいて夜にストレッチだけ行ってきた。夜のストレッチはいつもあまり調子よくないが、鍬仕事を少しやった分の筋肉痛などをほぐした感じ。今日の開脚幅は開始前153cmで、ストレッチ後155cmだった。

0時に寝て2時に起きて少し仮眠して5時に起きた。朝から出かける準備をして6時過ぎには出発した。神戸から実家まで約80kmの距離を、早朝だと高速道路が空いているのもあって1時間弱といったところ。

軽トラのエンジンをかける

車のバッテリーがあがってしまったときに使う ジャンプスターター を昨年末に購入していた。また軽トラのバッテリーがあがってしまったようで、今回は母に使い方を教えながらエンジンをかけてみた。バッテリーにつなぐケーブルに boost ボタンがあってそれを押下してエンジンをかけるだけ。これは本当に買ってよかった。たまにしか農業しないような家の軽トラ向けにあると安心できる。軽トラのエンジンがかかったら1時間ほど走ってくればそれで元のバッテリーは回復する。

草焼き

実家に着いたのが7時過ぎで朝ご飯を食べて、まだ時間があったので草焼きを手伝うことにした。すでに刈って干した草が集めてあったのでそれを火にかけて番をする。以前にも草焼きをした経験 があったので注意を払いながら行う。母が言うには、最近でも淡路島の人で草焼きをしていて2人亡くなっているという。おそらく煙に巻かれて一酸化炭素中毒で気を失ってしまったんだと推測する。干し草は一気に燃え上がるので青い草と干し草を調整ながら火の勢いを制御する。あとは表面だけ燃えるので内側も燃えるように混ぜ返したり空気を送ったりといった調整も必要になる。火の制御は難しい。1時間ほどやっていた。

Python Boot Camp

今日の目的は次のイベントに TA として参加してきた。

• Python Boot Camp in 徳島2nd

現地11時集合だったものの、早めに実家を出たので10時半頃に着いてしまった。他のスタッフもその後すぐに合流して10時50分には全員が揃った。私は知り合いのスタッフがほとんどいなかったので挨拶したりしていた。だいたいスタッフは次のような構成だった。

• 講師: 1人
• 現地スタッフ: 1人
• TA: 3人
• 会場関係者: 2人

次の段取りでほぼこの通りうまくスケジュールを進捗できたと思う。

11:00 スタッフTA講師が集合
11:00-11:30 準備
11:30-12:30 スタッフTA講師でランチ
12:30 開場
13:00 PyCamp開始
17:00 PyCamp終了
17:30 撤収完了

お昼に食べた「鳴門うどん」もひやむぎ程度のサイズの麺をにゅうめんのような食感で食べるものだった。身近に住んでいてこれは知らなかった。おいしかった。

boot camp イベントも順調に進捗して受講者も喜んでいたようだったのでよかった。久しぶりにこういったイベントに参加すると、プログラミングを始めたばかりの気持ちなどを思い出してよかったと思う。いまはお仕事でプログラミングの随分と高度なことをマネージャーとして教えているわけだけど、簡単なコードが動いておもしろいといった気持ちがあることも大事だと思う。懇親会も出て、その後、スタッフ同士での反省会もやって、21時前には現地を解散して21時20分に実家に戻った。

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

隔週の雑談

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

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

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

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

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

昨日の続き 。

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

• Home > Google Workspace > Gmail > Guides > OAuth 2.0 Mechanism
• RFC 7628 - A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth 日本語訳

なぜか 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
}

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

• https://github.com/jacobalberty/smtpoauth2

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

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

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

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

• Turning off less secure app access to G Suite accounts
• Beginning September 30, 2024: third-party apps that use only a password to access Google Accounts and Google Sync will no longer be supported

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 経由でメールを送ることもできて、そのやり方と混同するとまったく違う方向に行ってしまう。そこだけ注意。

0時に寝て4時ぐらいに起きてだらだらして7時半に起きた。やっぱりあまり眠れない。

ステートレスな認証という概念

次の開発フェーズが始まっていて、ちょっと時間が経ってしまったが、前開発フェーズのお披露目的な製品紹介をお手伝い先の全社向けに行った。主には直近の開発フェーズで追加した機能などを紹介した。その過程で新たに認証の仕組みを追加して jwt で認証するといった話しをしたところ、それはステートレスなのかどうかといった質問が出た。セキュリティを考慮して、アーキテクチャ的にフロントエンドの認証と api サーバーの認証は分けて実装しているのと、そのために仕組みも複雑になっているのだけど、ステートレスという言葉が指す意図を私がよくわかっていなくて、うまく説明できなかった。説明を終えた後にアーキテクチャのイメージ図と一緒に補足をしながらやり取りして次の記事を教えてもらった。

• “JWT=ステートレス"から一歩踏み出すための考え方

jwt は暗号化の技術で認証する仕組みなので有効期限が切れるまでは有効なアクセストークンとなる。そのため、jwt のみだとログアウトという概念はないため、そこをどうしているのか？という質問だった。フロントエンド／api サーバーともに session をオンメモリで保持して、ログインしたユーザーを管理しているため、ログアウトしたら session からレコードを削除することで有効な jwt のアクセストークンが来ても認証エラーにしてしまうことでステートをもった認証方式を実現している。とくまる先生が次のように説明しているところ。

「セッションIDをJWTに内包する」 という考え方です。

うちはこれをセッション ID ではなくユーザー名でやっている。とくに難しいことをやっているわけではなく、普通に実装したらそんな感じかな？と考えていたが、jwt = ステートレス認証だと思い込んでいる人たちがいるから ストートレスな認証 というキーワードが出てきたんだなと理解できた。最近のトレンドとしてはログアウトで jwt のアクセストークンを無効にできないと脆弱性と指摘される可能性がありそうとも書いてある。

ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど)

私はアーキテクチャ的にブラウザに api サーバーのアクセストークンをみせないというところに注力して認証機能の開発をサポートしていた。それ自体も間違っていないとは思うけど、今回の質問はその工夫とは異なるところの質問だった。認証は難しい。

0時に寝て何度か起きて7時過ぎに起きた。眠れたような、そうじゃないようなよく分からない起き方をした。お昼ご飯を食べる間もなく、打ち合わせとコードレビューで1日を終えた。連休明けでよい慣らしになった。

税理士さんとの打ち合わせ2

税理士さん探し の続き。今回話した方は公認会計士だった。監査ができるのが公認会計士で、税務の申告ができるのが税理士という役割の違いになる。会計監査も含めてチェックしてほしかったら公認会計士さんにお願いするといった役割分担になるかもしれない。話してみて、若くて理路整然として悪い印象はなにもなかったのだけど、逆にこの人がうちの会社の会計／税務を親身にやってくれそうにもみえなかったし、ホームページの事業内容をみても公認会計士だから税務のビジネスだけではなく、もっと大きな会計のお仕事の方がを目指しているようにもみえた。同じ質問をして、前回の税理士さんの回答の違いなども考慮しながら選定の判断材料にはなるなと思いながらやり取りしていた。選択する側の打ち合わせはおもしろい。

アーキテクチャの再考

お手伝いしているシステム開発で、私の中ではもうアーキテクチャは固まったかな？と考えていたのが、お客さんと話していて、さらなる要件や展望を聞いているとそうじゃなかったことに気付いた。どうやら最初の実装としてはいまのアーキテクチャを堅牢に作って、その次の要件として待っていてくれたようにみえる。

私の認識を正す意味も含めて、さらにお客さんの要件や世の中の競合製品に対して競争力をもつにはどうするかといった視点をざっくばらんに雑談した。もう1段階アーキテクチャを見直す必要があるなと思えた。開発に着手して今月末でちょうど1年が経つ。これまで大きなアーキテクチャの変更もなく、順調に開発は進んできたものの、ここらで見直しやズレの補正が必要になってきてもなんらおかしくはない。いまの開発フェーズでは対応しないが、次の開発フェーズに向けてのアイディアの1つとしてアーキテクチャの再考が必要なことを認識した。

22時に寝て何度か起きて7時に起きた。一昨日からイスラエルとパレスチナの背景の調査をしていて、だいぶあてられてしんどくなってきた。歳のせいか、誰も幸せにならない難しい問題を調べているとしんどくなる。

23時頃から寝始めて3時ころに吐き気で苦しんで7時に起きた。寝る前にちょっとお菓子食べたのがよくなかったのかもしれない。

イスラエルとハマスの戦争

昨日の夕方からハマス (パレスチナ) がイスラエルにロケッ弾を打ち込んだというニュースをみていろいろ調べていた。ハマスはパレスチナのガザ地区を実効支配するイスラム組織だそうで、からなずしもパレスチナを代表しているわけではないらしい。パレスチナにもファタハと呼ばれる穏健派もあるそうで一枚岩ではないとのこと。経営者になると、こういった世界のニュースに対して経済への影響が気になって情報収集してしまう。イスラエルとパレスチナの2国間の問題はとても難しいものになっているようで、どうやって解決するのか、誰もアイディアのないまま、いまに至っているようにみえる。是非はとまかく、どちらかがどちらかを滅ぼすしかないのかもしれない。いまのところ、イスラエルとパレスチナの紛争は日常と言えるほど起こっていて、その2国間でドンパチするなら世界経済に大きな影響はないだろうとみられている。一方で今回は規模が大きいのと、一般市民への虐殺や犯行もみられることから、もっと大きな戦争に発展する懸念もみられている。ウクライナとロシアの戦争とも影響して台湾有事への懸念も、リスクは低いかもしれないが、ないわけではないとみられている。

• パレスチナ問題ってなに？ １からわかる！イスラエルとパレスチナ（１）
• 【現状まとめ】イスラエル「戦争状態」
• パレスチナとイスラエル、今年だけで200人死んでるよ。

0時に寝て何度か起きて7時に起きた。2-3日前から首を寝違えていて違和感がある。課題管理のブログ記事を書こうと思っていたけど、気分がのらなくて遊んでいた。

ストレッチ

今週も忙しくはなく、のんびり過ごしていたので体調は徐々に復調している。腰の張りは先週に比べてかなりよくなっているように感じた。トレーナーさんによるとふくらはぎの筋の張りがあったそうだけど、私からみたらそんなに気にはならなかった。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。首を寝違えているのもなにかしらよくなる方法があるかと思って相談してみた。トレーナーさん曰く、首の寝違えだけは自然治癒しか方法がないという。トレーナーさんたちの間でもいろいろ試してみたことがあるらしい。しかし、どれも一時的に痛みを和らげる効果のあるストレッチはあるものの、時間が経つと元に戻るので限定的なものらしい。その一時的に痛みを和らげるのも、脇の下の筋を伸ばすと効果があるらしい。トレーナーさんもなぜその筋を伸ばすと痛みが和らぐのかの理屈はよく分からないそうだが、実際に試してみてそこだけが効果があったと話されていた。

Python Boot Camp

来週、徳島の鳴門でイベントがある。いま余裕もあるのでスタッフが足らなかったら手伝ってもいいと、前にてらださんと話していた。ちょっと前まで参加者が1人しかいなかったので手伝う必要ないかと思っていたんだが、ここ数日でいっきに参加者が増えたみたいで助っ人で手伝いに行くことにした。ブートキャンプに参加するのは初めて。チュートリアルやスタッフの要項などのドキュメントを予習として読んでいた。

Python Boot Camp in 徳島2nd

ヨハクさんのフレークシール

たまたま「余白」というキーワードでインターネットを検索していて次のサイトをみつけた。

• https://yohaku.stores.jp/

マスキングテープの専門店らしいが、なんとなく制作物の世界観が私にあうので応援も含めて次のフレークシールを買ってみることにした。

• CATEGORY / Flake seal

3種類買ってみて、今日届いたので、試しに一緒に入っていた型紙に貼ってフレームに入れてみた。こういう雰囲気が好き。しばらくオフィスの棚に飾ってみようと思う。

• ツキトホシ
• ダイアリー
• テガミ

1時に寝て3時頃に吐き気で起きて1時間ぐらい苦しんでた。久しぶりにやばかった。その後なんとか寝て7時半に起きた。

税理士さんとの打ち合わせ1

うちの会社のイベントとして毎年ワーケーション (開発合宿) をやろうかと考えている。コワーキングやコミュニティの延長上でワーケーションを行うわけだが、いくらかうちの会社の持ち出しで費用負担してよいと考えている。しかし、そのときの支出はどういった建付けで経費として扱えるのかどうか、私は税理士ではないのでよくわかっていない。そういったことを相談するために税理士さんに顧問になってもらおうと考えている。うちから税理士さんへの要件としては freee のデータを正として扱ってくれればそれでいいかな。

また2021年度は赤字決算になったので2022年度に 法人税の欠損金の繰り戻し還付 を行った。このお金を2022年度に計上していないため、その分の金額が資産のマイナスとして2023年度の決算に残ってしまっている。法人税の支払いは正しいのだが、還付金を2023年度に雑収入として登録するか、2022年度に遡って未計上の金額を登録するかのどちらかで訂正しないといけない。過去の法人決算の訂正自体も行う仕組みはあるので手続きするだけだが、それも手間暇がかかるのでついでに税理士さんにやってもらうと考えている。

• 税理士・会計士にfreeeの情報を共有する

会計システムに freee を使っているので freee さんの税理士紹介サービスを使って選定する。3事務所ピックアップしてくれたので順番に打ち合わせしていく。今日はその最初の税理事務所の方と打ち合わせした。話した感覚でうちの会社の考え方や規模にあった税理士さんだったのでこの方でいいんじゃないかとも思っているけれど、せっかく他の事務所もピックアップしてくれたので他の税理士さんの話も来週また聞いてみる。

コードレビュー

まる一日コードレビューをしていた。私もマージリクエストを投げていてレビューしてもらいつつ、メンバーのコードレビューも順番にやっていった。その中で smtp の仕様を把握しておく必要があっていくつかシニアエンジニアの方からもアドバイスをもらって、私もそうだったんだと勉強していた。メールヘッダーのエンコーディング、昔は覚えていたけど、ずっとメールを送るコードを書いてなかったので私も忘れてしまっていた。こういうことをさらっと指摘できるのがシニアエンジニアのすごいところ。

• sendmail コマンドによるメール発信 - Postfix Advent Calendar 2014 - ダメ出し Blog

go だと標準ライブラリに mime パッケージがある。mime パッケージを使って件名を utf-8 でエンコーディングされた文字列で指定すると次のようになる。q エンコーディングと b エンコーディングの2種類がある。b エンコーディングの方がデータ量が減ってよさそう。

fmt.Println("Subject: " + mime.QEncoding.Encode("utf-8", "テスト"))
fmt.Println("Subject: " + mime.BEncoding.Encode("utf-8", "テスト"))

Subject: =?utf-8?q?=E3=83=86=E3=82=B9=E3=83=88?=
Subject: =?UTF-8?b?44OG44K544OI?=

• https://go.dev/play/p/zQjMMp17bKf