22時に寝て何度か起きて6時に起きた。もうがんばれない状態。本当はお仕事すべきではあったんだが、モチベーションが売り切れてしまって違うことした方が気分転換になりそうなので翻訳していた。

ストレッチ

先週が疲労のピークだった気がする。先週よりはましになったものの、右足全般がやばい感じだった。かなり辛かった。ここ1-2週間、歩いていて知人からも足悪いの？と聞かれるぐらいには、まともに歩けなくなっているようだ。あと何年歩けるのだろう？という危機感も少しある。腰もやや右側の張りが強かった感じはした。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。先週よりは少しだけ改善した。ただお仕事のピークは超えたのでこれから少しずつ回復していくといいなと想定している。

deepl で翻訳したものの手直し

来週の LT 発表ネタの準備。

ある英語の記事を紹介するにあたり、その日本語翻訳を用意しておこうと考えた。要約をちょろっと話して詳細はこれ読んでねみたいな LT にしようと思う。先週から著者に翻訳の許諾をしてほしいというメールを送っていたが1週間経っても返信なし。著者との別のコンタクト方法の1つに linkedin があった。linkedin でメッセージを送ると3時間後に OK の返信がきた。そっか linkedin だと、相手がどんな人かといった情報がわかるからメールよりも返信するモチベーションになりやすいのかもしれないと気付いた。少なくともスパムではないと確認できて安心できる。今後は linkedin で dm を受け付けている人には linkedin を積極的に使っていこうと思った。

今回は deepl を使って翻訳しようと考えていた。プロライセンスを購入していれば、翻訳した成果物の著作権を主張しないと規約に書いてある。基本は deepl で翻訳するものの、「てにをは」を直したり、スキップされた文章を再翻訳したり、訳文がおかしいところを見直したり、あとテーブルや図の英語を手入力して翻訳したりとか、あと細かいレイアウトの調整とか、文章量が多かったのでそういった細々したことをやってたら7時間ぐらいはかけたと思う。

ポッドキャストを聞きながら手を動かしていたり、途中で晩ご飯を食べに行ったりしながら、お昼から始めて夜中の2時前ぐらいになって、もう眠くなって推敲に疲れて、半分ぐらいチェックし終えたところで公開しちゃうことにした。公開した方が慌てて直すモチベーションになるから意図的にそういうことをするときもある。

• (翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎

今日はもう眠くて無理で公開後、家に帰ってすぐに寝てしまった。

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

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。先週は多忙でお休みした。今日の議題はこれら。

• santiago 氏のスクラム批判の話題
  • Scrum is a cancer.
  • Software estimates are one of the oldest lies we tell ourselves.
  • I wrote, “Scrum is a cancer,” and the Internet had thoughts about it.
  • Story Points don’t work.
• オープンセミナー2023@香川 で LT する話題
• 角印のデータ化の共有

たまたま X (twitter) でスクラム批判しているツィートを教えてもらってリンクにあるように Scrum is a cancer. というインパクトのある書き出しで聴衆を一気に掴んで盛り上がっていた。多少の誇張はあるものの、内容も真っ当で私が読んでみてもそんなに違和感がなかった。スクラムの懸念をうまく言語化したポストになっていたと思う。その延長で他にも、見積もり、フィードバック、ストーリーポイントにも言及していて、これらの話題についてはらさんと雑談してみた。はらさんとは1-2年前からスクラムの話題で何時間も話しているので、もうお互いに食傷気味ではある。ただ時事ネタなのと1年ぐらい経ったらアップデートもあるかな？という期待もあって話題に選択してみた。次のような意見が出た。

• スクラムの開発プロジェクトをそんなに経験している開発者は少ないから主語が大きくなりがち
• マネージャー入門としての、スクラムという開発方法論を評価してもよいのでないか？
• 「スクラムにはマネージャーいない」と骨髄反射で返答をよくもらうがそれは理想論ではないか？
• スクラムの失敗と事業／業務の失敗は違う
• スクラムは毎日見積もり、デイリースクラムで確認できるというメリットがある
• スクラムはチームの限定合理性を重視するため、個人の限定合理性を重視するメンバーを排除できる
• スクラムの懸念の1つに全然できていないのに「できている」というメッセージを出し過ぎるのではないか？
• ソフトウェア開発は前提として見積もりできないという認識をもつべき

お腹いっぱいなので詳細はあまり書かない。

オフィスの担当者との電話

先日の 暑さ対策委員会 の続き。

昨日、運営会社にその後の進捗を確認するために電話したらお休みだったので再度電話した。昨日もコールバックすると言いながら15時過ぎてもコールバックがなくて、もういい加減エスカレーションして偉い人に正式なクレームをあげようと考え始めていた。ようやく電話つながったと思ったら通話の音質が悪くて話しているうちに切断して、その後もつながらない。本当にイライラがつのる。2回目のコールバックで話していると、エアコンの工事によって隣のオフィスの人たちは問題ないと言っていたといったコメントが出てきた。

私のイライラが最高潮に達したのはこのとき。私はこれまでもずっと隣のオフィスの社員さんと暑さどうですか？という会話を何度かして先方も室内は暑いという話しを聞いていた。隣のオフィスの社員さんが問題ないなんて言うわけがないと思って、そのまま隣のオフィスへ言ってそこの社員さんにも電話に出てもらった。もちろん隣のオフィスの社員さんはこの件について一切やり取りしていない。社員さんも「(暑さについて) すぐ分かるから現場に来いっ！」って怒っていた。

ほんとその通りで7月の中旬からずっと伝えている。何もしていないわけではないのは理解するが、現地で確認したらこれまでの施策の効果がないことは一目瞭然である。一切確認せずに作業したから問題ないと判断して放置していたようにみえる。一連の対応が終わったときに正式なクレームとして運営会社にあげようと考えている。

• 1ヶ月半の間に5回電話して一度もコールバックも進捗報告もなかった
• 効果が出ていないことは報告しているにも関わらず、なんら施策を検討していない
• 現地で確認すれば、ひどい暑さであることがすぐわかるのに1度も調べようとしなかった

0時に寝て何度か起きて6時に起きた。1-2週間前に2年ほどやっていたドラクエタクトをやめた。飽きたのか自然ともういいかって感じでやめられた。それ以来、家に帰ってからゆっくり休む時間が増えた気がする。

qa という業務の懐の広さ

先週の水曜日から qa テストに移行している。スケジュールとしてはこのために1ヶ月を確保している。おそらくもう少し早く終えられるんじゃないかという気はしている。早く終われば次の開発の計画づくりを前倒しにすればよいのでそれは構わない。私は先週から残タスクのリファクタリングが終わりきらなかったのでややバタバタしていたが、メンバーはテストに専念してテスト環境で動かして意図しない振る舞いを issue 登録したり、直感とは反する振る舞いを issue 登録したりしている。

新人さんや、未経験だけと開発者になりたいとジョブチェンジする人たち向けに、最初のキャリアとしてテスターや qa をするのがよいのではないかと私は考えている。きっかけは More Joel on Software に、テクニカルサポートは開発者を配置する必要があると書いてあった。しかし、テクニカルサポートだとスキルを身につけると持て余してしまうため、その業務ためのキャリアパスを考えないといけないと書いてあった。まったく同感だ。私がお手伝いしたある会社でもテクニカルサポートは1-2年で辞めているのを見聞きした。みんな開発したいからね。

(おまけ) カスタマーサービスの人たちのためのキャリアパスを用意する

• テクニカルサポートにはデバッグ能力を要求するため、資質の高い人を配置する必要がある

More Joel on Software

新卒以外の採用ルートで未経験から開発者になるのは、いまは相当に難しいと思う。そんな人たちがキャリアアップするための試金石としてテスターがよいと思う。重要なお仕事だし、テストツールをプログラミングすることで開発者になるための準備期間 (学習) にもあてられる。システムの振る舞いや知識もテストを通して身につけられる。このお仕事を2-3年務められて、プログラミングも少し理解できるようになって、それでも開発者になりたいという意志があるなら開発者にステップアップすればよい。適正があるかどうかわからない状態で開発者を始めるよりも、ゆっくり学んでいけるのでうまくいくのではないか？と思ったりする。うちの会社はまだ社員を雇う余裕がないので私の持論の検証はできないが、どこかの会社でやってみてほしい。

22時から寝始めて何度か起きて6時に起きた。最近は早寝早起きにしている。

client ライブラリのトークン認証対応

いまの開発の新機能の1つにローカルアカウントの管理機能がある。普通のパスワード認証により、JWT によるアクセストークンを発行し、リフレッシュトークンを使ってアクセストークンの再取得を行う。api サーバーで実装してもらったこれらの web api を使って、api client 側でもログインしてアクセストークンを取得して web api のリクエストができるようにする。一般的にアクセストークンは有効期限が短いため、有効期限が切れたときは透過的にリフレッシュトークンを使ってアクセストークンを再取得する。またリフレッシュトークンの有効期限が切れたときは再ログインして、アクセストークンとリフレッシュトークンを再取得する。

文章で書けばこれだけの機能だけど、このための AuthProvider を実装した。最終的には次のインターフェースになった。

type AuthProvider interface {
	CanRefresh() bool
	GetAuthorization() (string, error)
	GetType() AuthType
	Refresh() error
}

先週たまたま Azure/azure-sdk-for-go の AuthProvider のソースコードを読んだ。やりたいことに対して、かなり複雑なことをしているようにみえたが、アクセストークンのキャッシュ、有効期限が切れたときのリフレッシュを透過的に行うコードだった。このライブラリの実装が読みにくいコードで、私だったらもっとシンプルに実装するというイメージが先週からあったのでそのイメージ通りに実装して1日で対応を終えた。本当はこの機能をいまの開発フェーズで提供する予定はなかったんだけど、うまく簡潔に実装できたので一部 agent で導入してテストで検証することにした。

22時頃から寝ていて2回起きて3時に起き出して、4時までネットみたりしていて、また寝て6時に起きた。生活のリズムがおかしい。

コンテナー間のデータのやり取り

昨日 モジュール分割 したことにより、いままで1つのモジュールで管理していたが、モジュールを分割したのでそれぞれのバージョンを取得できるとよいという話題が出た。コンテナー内にアプリケーションのバイナリがあり、バイナリを実行するとバージョン情報を取得できる。それぞれのモジュールは独立したコンテナで動いてるため、コンテナー間でその情報を受け渡す方法が必要になる。ググってみると次の so がヒットして named pipe がプラクティスだという。

• How to run shell script on host from docker container?

ホスト os 上の named pipe をコンテナーの volumes でマウントして、それぞれのコンテナーが読み書きすればよい。構築時に named pipe さえ作ったらコンテナー内での読み書きでデータ通信を実現できるため、シンプルでよいんじゃないかと思えた。

mypipe という named pipe を作る。

$ mkfifo mypipe

読み込み用コンテナーのための read-Dockerfile を作る。tail コマンドで named pipe を読む。

$ vi read-Dockerfile
From bash:latest

ENTRYPOINT [ "tail", "-f", "/app/mypipe" ]
$ docker build -t mypipe-read:latest -f read-Dockerfile .

named pipe をマウントして読み込み用コンテナーを起動する。

$ docker run --rm --mount type=bind,source="$(pwd)"/mypipe,target=/app/mypipe,readonly mypipe-read

書き込み用のエントリーポイントのスクリプトはちょっと工夫がいる。おそらく Dockerfile 内で直接リダイレクトの操作ができない (やり方がわからなかった) 。シェルスクリプトを呼び出す形にして、シェルスクリプト内部でリダイレクトにより、named pipe に書き込みする。

エントリーポイントのスクリプトは次のような感じ。eval "$@" で任意のコード実行できるようにちょっと細工。

$ vi myentrypoint.sh
#!/bin/sh

cleanup() {
    echo "cleanup ..."
    exit 0
}

trap cleanup INT TERM

while true
do
    echo "$(date)"
    eval "$@"
    sleep 1
done

書き込み用コンテナーのための write-Dockerfile を作る。先の myentrypoint.sh を ENTRYPOINT として起動させる。

$ vi write-Dockerfile
From bash:latest

COPY myentrypoint.sh /app/
RUN chmod +x /app/myentrypoint.sh

ENTRYPOINT [ "/app/myentrypoint.sh" ]
$ docker build -t mypipe-write:latest -f write-Dockerfile .

適当に乱数を生成する cli を eval 実行させる。

$ docker run --rm --mount type=bind,source="$(pwd)"/mypipe,target=/app/mypipe mypipe-write "tr -dc 0-9 < /dev/urandom | fold -w 8 | head -1  > /app/mypipe"

読み込み用コンテナーで乱数を表示できるはず。

なにも難しくなく、linux の標準の機能を使ってコンテナー間のデータ通信を実現できたことにちょっと驚いた。

go で named pipe を読むときは linux ならば syscall.O_NONBLOCK を指定することで書き込みしていなくてもブロックせずに読める。値を取得できない可能性はあるけど、それが許される要件ならこれで済む。またテックブログにまとめたい。

func readNamedPipe(path string) ([]byte, error) {
	flag := os.O_RDONLY | syscall.O_NONBLOCK
	pipe, err := os.OpenFile(path, flag, os.ModeNamedPipe)
	if err != nil {
		return nil, fmt.Errorf("failed to open path: %w", err)
	}
	defer pipe.Close()
	reader := bufio.NewReader(pipe)
	b, _, err := reader.ReadLine()
	if err != nil {
		return nil, fmt.Errorf("failed to read line: %w", err)
	}
	return b, err
}

0時に寝て何度か起きて6時に起きた。そのまま7時過ぎまでだらだらしてた。しんどい。

msgraph-sdk-go のサイズ問題

先週 msgraph-sdk-go を使った開発 を終えてデプロイする段階になってライブラリのサイズが大きくて、コンパイル速度が遅くなったり、バイナリサイズが大きくなったりする弊害があることに気付いた。コンパイル速度は2-3倍遅くなり (3分が7-10分ぐらい)、バイナリサイズも2-3倍大きくなる (30 MiB が 100 MiB とか) 。たまたまこのリポジトリは他のツール類からも依存パッケージとして使われるものなので想定よりも影響が大きいことに気付いた。

朝からチームのメンバーとミーティングして、本来は qa に入ったこの時期にこんな変更をすべきではないが、これは放置するデメリットが大きいのでリポジトリ分割 (モジュール分割) しようと提案して了承を得た。私がやれば作業は1日もあれば完了するだろうと見積もって、見積もり通り、夕方には分割したモジュールをテスト環境にデプロイして当面の解決を得た。アプリケーションのモジュール構造をちゃんとレイヤー化して作ってあるから、今回みたいに急遽、モジュール分割が必要になってもほぼ変更する必要はなかった (たった1箇所だけ) 。

この本質的な問題は次の issue のコメントで説明されている。

• Issue with the size of the API surface of the models package #129

ざっと機械翻訳してみる。

コンテキスト

この SDK は kiota を使用してメタデータから自動的に生成されます。オリジナルのメタデータは、Microsoft Graph の配下にあるすべてのサービスチーム（v1用とベータ用）によって入力された CSDL です。この CSDL は最終的に OpenAPI のフォーマットに変換されますが、これは非常に大きなものです（1k 以上のエンドポイント、1.5k のモデル …）。API のサイズが大きいため、完全な API surface の SDK を手作りすることは実現不可能でしょう。

私たちは、SDK を複数のサブモジュール（ファイル用、メール用など）に “スライス” して、人々が関心のあるものだけを簡単に入手できるようにすることをしばらく考えてきました。実際、私たちは PowerShell でこれを実現しました。しかし、“グラフ” の性質（すべてのモデルは互いにある程度関連している）と構築されるアプリケーションの多様性により、スライスは誰にとっても “正しい” ものにはならない（大きすぎたり、小さすぎたり、モデルの重複につながったり…）。

そのような理由から、私たちは「完全なSDK」を提供することにしました。すべての人にとって理想的とは言えないかもしれませんが、Go開発者の中には「アプリケーションを作るためのSDKが欲しいだけ」という人もいると感じています（以下で説明する2つ目のオプションとは対照的です）。

Go の欠点

Go の探求を通して、いくつかの欠点に気づいた。現時点では、私たちのプロジェクトやパッケージが適切にセットアップされていないせいなのか、Go や大規模プロジェクトの制限のせいなのかはわからない：

go build は、変更されておらず、依存関係も変更されていないサブパッケージをリビルドすることが多い。go build が直前に実行されていても、go test がリビルドすることがよくあります。なぜある種のキャッシュに頼らないのでしょうか？同じ問題が go lint にもある。
私には、たくさんのサブパッケージがある大きなプロジェクトをビルドするコストは、依存関係が更新されたり、キャッシュが削除されたり、コードが変更されたりしない限り、「セッションごとに一度」だけ支払われるべきだと感じます。

私たちのプロジェクト構成／構造において、そのような状況を改善するための最適化について、自由に概説してください。また、Goコミュニティ（Goコンパイラを開発している人たちなど）と関わって、そのようなフィードバックを提供する方法があれば、喜んでそうします。私たちのプロジェクトは、その規模の大きさから、世の中にあるほとんどのGoパッケージと比べると、ちょっと変わり者だとわかっています。

適切なサイズの SDK

最後に、すべてのエンドポイントを備えた完全な SDK を持つことは、様々な理由からすべての人に適しているわけではないことを認識しています。私たちは新しい “適切なサイズのセルフサービスSDKエクスペリエンス” を可能にするために取り組んでいます。そこでは、APIユーザーは誰でも、この SDK と同じように見え、同じように感じる SDK を生成することができますが、完全な API サーフェスの代わりに、彼らのアプリケーションのために彼らが気にするエンドポイント/モデルのみが含まれています。 私たちは今、そのような取り組みに本当に早くから取り組んでいますが、それでもフィードバックをいただけるとうれしいです。大まかな手順はこんな感じだ：

1. 新しいgoプロジェクトを作成するか、既存のプロジェクトを特定する。
2. kiotaの依存関係を追加するか、msgraph-sdk-go-coreを追加します（これはKiotaの依存関係をプルし、いくつか追加します）。
3. グラフエクスプローラで必要なリソースを選択（左パネル、2番目のタブ、…、“コレクションに追加”）。
4. コレクションをプレビューをクリックし、postmanコレクションとしてエクスポートします。
5. hidi を postmanコレクションと先ほど共有したOpenAPIの完全な説明文と一緒に使って、“フィルタリングされた” OpenAPI フォーマットを生成する。
6. kiotaを使って、プロジェクトにMicrosoft Graph用のGoクライアントを生成する。
7. APIの呼び出しを開始する。

この時点で、私たちはこれらのステップをすべて文書化し、効率化するために取り組んでいます（おそらくステップ4～5を圧縮しています）。このアプローチの素晴らしいところは、ステップ5から7までが、Microsoft Graphだけでなく、呼び出したいOpenAPIで記述されたAPIで動作することだ。
繰り返しますが、この最後の提案はまだ初期段階です。自由に試して、様々な場所でフィードバックを提供してください。

この長い投稿で、私たちがどこに向かっているのかが明らかになり、Goコミュニティからこれらの側面すべてについてさらにフィードバックが得られると本当に助かる！

簡単に言えば、ms graph api の体系が巨大過ぎて、その定義は openapi.yaml にあるが、この定義からすべてコード生成すると巨大なモデル定義をもつ sdk が出来上がってしまったという話しである。後半に書いてあるワークアラウンドとして kiota で必要なモデルだけを選択して専用 sdk を生成すればサイズを小さくできるとある。しかし、それはそれで graph explorer で選択しないといけなかったりして面倒そうではある。次のドキュメントでもその手順について書いてある。

• Create a smaller and tailored Microsoft Graph Go client library

うちの用途ではモジュール分割により、局所化したのでひとまずこの問題は大きな影響をもたないようになった。また余裕があるときにモデルを選択して専用 sdk を自動的に生成する仕組みを構築できるならそれに挑戦してもよいかもしれない。

0時に寝て3時5時7時と起きて8時に起きた。起きてからネットの記事を読みながらしばらくだらだらしていた。11時ぐらいにはオフィスへ行って今月分の請求書を発行して、9月のイベントで発表するネタの調査、三ノ宮.dev の slack で 課題管理について話した podcast を紹介してもらったお礼を述べたりとか、いろいろ自社のお仕事をしていた。

マイクロ法人のススメ

たまたまだが、私がよく行くお店でマスターが1人でやり繰りしている飲食店が増えてきた。またコワーキングスペースなどへ行くと、マイクロ法人でがんばっている人たちと交流する機会も増えてきた。私自身マイクロ法人として1人で会社や事業を経営している立場なのでそういった似たもの同士な人たちとよく気があう。同じような人たちをみていて、マイクロ法人のなにが楽しいのかを、いずれちゃんとしたブログの記事にしたいと思う。外から観察していても働き方に共通点がある。

よいところを述べる前に、わるいところも言うべきだと思う。

• (サラリーマンと比較して) 会計や税制といった財務知識が必要になる
• (サラリーマンと比較して) 書類などの事務手続き作業は増える
• (サラリーマンと比較して) 短期的な安定や信頼を得にくい
• 自分で営業しないといけない
• 自分で事業を設計しないといけない
• 同僚と雑談できない、困ったときに助けてもらえない
• 複数人で対応するような規模の大きな仕事はできない

たくさんわるいところもある。これらのわるいところを受け入れた上でよいところもある。

• お仕事はすべて自分で決められる
• 目標設定をしなくて済む (他者評価もされなくて済む)
• (サラリーマンと比較して) 事業がうまくいけばより大きな対価を得られやすい

デメリットよりもメリットが上回るのならマイクロ法人がいいと私は思う。もちろん若い人には勧めない。経験のある人が評価されずにつまらない組織の仕事で残りの余生を過ごすぐらいなら、自分で思うよう好き勝手働いた方が人生としては楽しいのではないかと思ったりする。もちろんそれで失敗する人もいるだろうし、私も今後失敗するかもしれない。失敗したときに会社を辞めずにサラリーマンをしておけばよかったと後悔する日が来るかもしれない。仮に失敗したとしても、その瞬間までのマイクロ法人で働いてきた日々に価値を見出せればそれだけでよかったと思えるかどうか、と言い換えられるかもしれない。

楽しく働く

うちの会社の価値観の1つにしようと考えている。歳をとってシニア社員になるほど、楽しく働いている人は少なくなっていくように傍からはみえる。会社から評価されず、おもしろい仕事も任されず、ただ生活のために働いている人は多いのだろう。状況が許せば、そんな人がマイクロ法人になると、働く楽しさを取り戻せるかもしれない。

23時に寝て何度か起きて6時に起きた。疲労でバテバテ。

ストレッチ

先週もあまりよい状態ではなかったけれど、今日はことさら悪かった。疲労は着実に蓄積するんやと実感する。左足は筋肉痛やなって感じだけど、右足はそのうち足が動かなくなるんじゃないかとすら思えた。ふくらはぎは左右ともにパンパンだし、右の股関節の部位はピキッて感じで痛みが出たりするから根本的に悪そう。足全体が硬かったように思える。腰もいくつか張りがあって、特定のツボはかなり痛くてなにかが悪いのだと思えた。臀部のツボも一部だけすごく効いて痛かった。肩周りも凝りや張りはいつもより大きかったように思う。今日の開脚幅は開始前154cmで、ストレッチ後156cmだった。久しぶりにこんな調子の悪いのも珍しいなと思えた。あと2週間ぐらいがお仕事のピークだと思うのでもう少しだけもてばよい。

請求書のテンプレート作り

10月から施行されるインボイス対応の請求書として 10%, 8% の消費税の税率を明記して別々に小計を記載しなければならない。そろそろ個々の企業でも運用が始まるところ。うちの会社が扱う商品は10%のみだが、請求書のフォーマットそのものを変更しないといけない。ちょうど freee 側でもその対応で6-7月に新しい帳票管理の機能をリリースしていた。8月から順次切り替えとなっていた。私は開発にいっぱいいっぱいだったからベータ版は見送って正式リリース後に対応することにしていた。それが今日だ。今月分の請求書はインボイス対応の新しいフォーマットで作る。

その移行をしていて、この機会に会社のロゴや角印も請求書に載せることにした。はらさんに角印をどうやってデータ化したらよいかを尋ねたら、普通に白い紙に押印してスキャナで取り込んで、白色を透過処理して使っているとのこと。

オフィスの複合機で白い紙で押印した角印をスキャンする。pdf でダウンロードできる。pdftoppm で pdf を png に変換する。

$ pdftoppm -png corporate-seal-square.pdf corporate-seal-square
$ ls corporate-seal-square-*
corporate-seal-square-1.png  corporate-seal-square-2.png

あとは白い背景を透過処理するだけ。pinta, incscape とやってみたけど、どうもうまくできない。最終的に次の記事を参考にしながら gimp を使って「ファジー選択」で透過処理したいところをちょこちょこ選択しながら変換していくのがもっとも私にとって簡単だった。

• GIMP – 画像を切り抜き背景を透明・透過して保存する方法

請求書のテンプレートに対して角印を読み込んで、社名に重なるように配置するのが慣習らしい。なぜ社名に角印を重ねるかというと偽造や改ざんを防止するという意図になる。電子データの請求書に角印を載せる意味はないけれど、紙の慣習にあわせるという意図なら重ねた方がよいだろうと考えて社名に角印を重なるようにして作成した。請求書に角印とロゴが入って見栄えもよくなった。

立ち呑み屋 本番

先週行った立ち呑み屋 さんにコミュニティのメンバーと一緒に行ってきた。ずっと休日も開発してきて疲労困憊ないので気分転換しようという思いつき。

19時開始でたまたまオフィスを出たときに雷が鳴り始めて、私がお店に付いたすぐ後に豪雨になった。今日はついている。豪雨は1-2時間で止んでいたと思う。その後、さなださんとすみよしさんと合流して飲んでた。わいわい雑談できて楽しかった。いくつか始めて注文してみた料理もおいしかった。このお店の料理は何を頼んでもおいしい気がする。お酒も料理もマスターが1人で運営しているせいか、非常に良心的な価格設定になっている。もう1.5倍ぐらい値上げしたらいいんじゃないかと思う。それでも安い方だけど。立ち呑みだとしんどいので22時前にはお開きになった。長居せずに帰りやすいのも立ち呑みのよいところだと思う。

1時に寝て何度か起きて7時に起きた。昨日は少し早めにお仕事を終えて家で休んでいたので少し回復した。

msgraph-sdk-go を使った開発

昨日の続き 。前日に作ったマージリクエストをチームのメンバーにレビューしてもらっていくつか修正して、マージを終えた。一段落。

さらにこの sdk を使うことで8月の前半に開発していた差分比較のところも変更しないといけないことに気付いた。public な構造体のメンバーにアクセスして差分比較する処理を実装していたが、この sdk は getter で構造体のメンバーにアクセスしないといけないことに気付いた。reflectoin の処理に追加で実装を入れるだけなのでそんなに難しくはない。そういった修正をしていたら1日終わってしまった。開発していると時間が過ぎるのは早い。

たまたま ci/cd ジョブの実行時間の上限を10分にしていて超えるときがあってジョブが失敗した。 調べてみると、msgraph-sdk-go の api が巨大過ぎてメモリを浪費したりコンパイルに時間がかかったりするという issue をみつけた。

• Memory Leak when creating msgraph client #436

私のローカル環境で測ってみると、約36秒で完了していたテストが2分23秒かかるようになっていた。テストの実行が4-5倍ぐらい遅くなった。さらにコンテナイメージのサイズは 36 MiB から 109 MiB と3倍ほど増えた。無駄に開発を遅らせる環境要因になっているのでこれは別途調査して対応しないといけないことに気付いた。

最終の新幹線で帰ってきて、2時に寝て2回ぐらい起きて8時前に起きた。寝坊した。7時頃に起きてない時点で疲れているんやろなと思えた。

msgraph-sdk-go を使った開発

昨日の続き 。ライセンスやグループのメンバーを扱うときの特殊な処理を実装してからマージリクエストを送った。本当は火曜日の時点でできたらよかったことが2日遅れになった。モチベーションがあれば、日曜日や月曜日の夜にできたことかもしれない。加齢のせいかもしれないし、私の中でまだ開発になにかが足りない。誰かから責められるわけではないが、自分で自分に嘘をつかないために自分なら間に合わせられたものが2日遅れになっているという事実にだけは気付いている。id 連携のビジネスロジックに相当するところの置き換えに4日かかったというのはノウハウがなかったらそんなもんという気もせんでもない。一通り実装できたのであとは qa テストで複雑なテストケースのバグ出しをすればよいだろう。

22時に寝て何度か起きて6時に起きた。カプセルホテルに泊まるときにいつも忘れることで、下の方のカプセルにしてもらうのをお願いすべき。おっさんには上のカプセルによじ登るのが辛い。カプセルホテルに泊まるので盗難防止を考慮して着替え以外はもっていなかった。パソコンがないので朝からやることもなくてお風呂入って、休憩スペースでのんびりしていた。

msgraph-sdk-go を使った開発

azure との id 連携のリファクタリング の続き。

microsoft 社のシステムの仕様が直感的でなかったり、sdk の api が使いにくかったり、この sdk を使うことの学習コストがやや高い。一方でドキュメントを読めば仕様はちゃんと書いてあるのでドキュメントを読みながら開発していくのがよさそうに思える。当たり前と言えば当たり前だが、ドキュメントを読まないと絶対に分からない仕様が多いという意味で学習コストが高い。

例えば businessPhones というプロパティはリストで設定するけれど、これは1つしか設定できないという仕様になる。2つ値を設定しようとするとエラーになる。

businessPhones String collection The telephone numbers for the user.
NOTE: Although this is a string collection, only one number can be set for this property.
https://learn.microsoft.com/en-us/graph/api/user-update?view=graph-rest-1.0&tabs=http#request-body

だいぶ sdk に慣れてきて、あともうちょっとのところだったが、今晩は予定があるので切り上げとなった。

年度末打ち上げ

お手伝いしているお客さんが8月が年度末になる。年度末の会社の打ち上げをやるのでよかったらどうぞとお声がけをいただいていた。うちのプロジェクトのスケジュールにあわせると定例を行う週の火・水の2日間だけ参加可能として予定を提出していた。他の社員さんの予定と調整して2週間もあるからそんなあわないだろう？と思っていたらあってしまって出張するしかないかと今回の出張が決まった次第だ。

17時半から東銀座へ移動して、ホテルの地下にあるちょっとよい雰囲気のレストランでお食事をいただいた。立派な陶磁器に芸術的な料理が添えられていて、おいしかったし、みて楽しむこともできて、会社で来ないと食べられないような内容で私はよかったと思う。食べものはコースだったが、若い人向けにはもっと量がないとお腹が空くだろうから追加でいくつか料理を頼んだりしていた。行ったことないレストランの量はわからないのでコースの選択は難しいと思う。

約55%の社員 (+お手伝い) が参加していた。欠席者の半分以上はリモートワークだったり業務都合で参加できなかったのを考慮すると、私用で欠席している社員は少数派にみえる。私用で欠席できるというのも多様性の文脈では大事だと思えるし、それでも7割ぐらいは参加する意志があるというのは組織としてのまとわりを表す指標の1つに思える。

私自身、昔はあまり会社の全体飲み会が好きではなく、チームや部署単位なら行くが、全社となると欠席する方が多かった。会社の中のよく知らない人たちと親睦を図ることにあまり価値を見出していなかった。しかし、いまマネジメントの立場で考えると、一定の理解はできるようになった。マネジメントとして社員に平等に報いる方法はかなり限定的であること。個別の社員ごとに好ましい方法で対応することはできないという現実がある。したがって、こういった全社的な催しもしかたないと言える。

そして、こういった場で人と人の結びつきや人間関係を良好に保つように、社員みんなが努力して組織が成り立っているのだとわかるようになってきた。 私は直接部門だから売上を上げてれば文句ないだろうとずっと思ってきたけれど、必ずしもそういった見た目の数字だけが会社を維持させているわけではない。目にみえない価値もたしかに組織にはある。 若い頃の私はその努力に欠けていた、もっというとフリーライドしていたという見方もできることに気付けるようになった。

その価値をいま風に言えばチームビルディングといったラベルがついている。それをどうやってうまく成し遂げるか、こういう場で見聞きすることの大事さもわかるようになってきた。だから、いまの私は自身にとって重要ではないイベントも後学のために役に立つかもしれないと前向きに参加するようになった。結局のところ、イベントを楽しむのもそうじゃないのも自分次第である。どんなことからも学べる。その学びがあるのならきっと楽しいと言えるかもしれない。社員旅行へ同行しての学び も大いにあった。

18時から始めて21時前でお開きになった。それから東銀座を出て9時24分の新大阪行きの最終新幹線に乗れた。新大阪に23時48分頃に付いて23時55分発の新快速に乗った。新幹線が2分遅れたことで新快速も2分出発を遅らせて57分発になった。その後、他にも神戸線で事故があった影響か、信号待ちがどうこうで芦屋あたりからずっと低速運行していた。最終的に三ノ宮には到着予定から17分遅れになった。疲れて早く帰りたいなと思っているときほど、こんなもんという印象。考え方を変えれば、いろいろあったのに、ちゃんと三ノ宮まで帰れてよかったと思えばそんなに気も悪くない。