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

me-id 調査

昨日の続き。システム構成をどうするか分かってきた。entra id に対するエンドポイントは基本的には Microsoft Graph API になる。これとは別に、自動プロビジョニングするには、entra id から scim 2.0 のプロトコルを用いてサードパーティサーバーに対してリクエストが送られる。entra id のエンタープライズアプリケーションという設定項目に google だったり slack だったりといったサードパーティのクラウド向けのアプリケーションが登録されている。それらが何をしているかというと、entra id から自動プロビジョニングによってリクエストされる scim 2.0 のエンドポイントの設定を提供している。そのエンタープライズアプリケーションにそれぞれのサードパーティサービスのエンドポイントの uri や credentials を設定する。entra id からリクエストを受け取って多少の加工などもしているかもしれない。

そこまで理解できたときにちょうどチーム勉強会があったので調査内容の中間報告のようなことをしていたら、オンプレミス AD にプロビジョニングするエンタープライズアプリケーションは microsoft 社が提供している。azure 上に windows サーバーを構築してオンプレミス AD を設定して自動プロビジョニングしたら、既存の agent から dirsync で id 連携できるんじゃないか？というコメントがあって、確かにその方がネットワークも考慮したシステム構成として理にかなっているし、うちらの開発コストが減って、すでに運用で使われている他社のアプリケーションも再利用できてよいかもしれないと思えてきた。明日はその検証をやってみる。

みなとのもりの運動

前回の所感 。オフィスから出掛けるすこし前に夕立が降ったらしく路面が濡れていた。天気予報をみたら降水確率は0%だったので一時的にざざーっと降ったようにみえる。この状態だと公園の芝生の上で縄跳びすると靴がずぶ濡れになるのでコンクリートの乾いているところの上で縄跳びをした。ひざに負担はかかるけど、コンクリート面の方が回数はたくさん跳べる。土の地面よりもコンクリート面の方が体力の消費も少ない。したがって休憩を挟まずに長く跳び続けられる。とはいえ、コンクリート面の縄跳びはひざへの負担が気になるから、今日は駆け足跳びをやめてジョギングしてみた。公園のトラック1周は約500mある。すこし前にジョギングできた ことから体重が減って股関節への負担が減ってジョギングも軽くならやってもよさそうな雰囲気が出てきた。休みながら2.5周走ってみた。

今日の運動は腕立て,縄跳び(両足跳,駆け足跳),散歩,ハンドグリップ,ダンベルをした。統計を 運動の記録 にまとめる。

me-id 調査

今週から Microsoft Entra ID (省略名は me-id) の調査をしている。ドキュメントはたくさんあるものの、機能や提供形態が多いために私がやりたいことを説明しているドキュメントがどこにあるのかを探すのが面倒だった。me-id から id 連携をするためのプロビジョニングを自分たちで実装したい。どうやらその説明のドキュメントは次のようにみえる。

• チュートリアル: Microsoft Entra ID の SCIM エンドポイントのプロビジョニングを開発および計画する

me-id としては sicm でプロビジョニングを行う api を提供していて、watermark と呼ばれる、rdbms で言うところの cursor のような仕組みで更新差分を取得する仕組みを提供している。scim client は microsoft 社も提供しているが、クローズドソースで windows 向けアプリケーションしか提供されていないため、自前で scim client を実装する必要があるということを月・火の2日間かかって理解できてきたといった進捗。なかなか難しい。

駐車場の契約

昨日の続き 。昨日の夜にオンラインで申し込みしたものの、いくつかフォームの記載事項に訂正を求めるメールが届いた。修正した内容を返信して数時間で審査を完了したから契約書を締結する連絡が届いた。普通に拒否されるわけはないのだけど、1度マンションのオーナー審査で拒否されてから法人契約の審査はわりとどきどきする。そして審査に落ちるとヘコむ。契約書や車庫証明関連の書類などは後日、郵送されることにはなるが、丸1日経たない時間で駐車場の契約自体はできてしまった。効率がよい。

みなとのもりの運動

前回の所感 。運動部のチャンネルにこの火曜日から木曜日までは 18:30 - 19:30 に公園へ行くと宣言して通うようにしている。こうやって公けに言ってしまうと引けなくなるので無理やりでも行くようになる。今日は18時半に雑用していたら出掛けるのが19時半になった。遅い時間に公園へ行った分、スペースは空いていた。いつも通り、シートを広げて場所取りしてストレッチをしていた。すると、短距離走のチームが近くに来て、ややパーソナルスペースに引っかかるといった所感をもった。向こうのチームもシートを広げてストレッチをしていた。同じようなことを考える人たちもいるもんや。今日は普通にストレッチして、縄跳びして、歩いてきて、ストレッチして、筋トレして、といつも通りのメニューをゆっくりこなしてきて満足した。

昨日は21時前に神戸に戻ってきて、オフィスへ行く元気もなくて、そのまま寝てた。0時頃に起きて2-3時ぐらいまでだらだらしていてまた寝て7時半に起きた。

今日の筋トレはレッグレイズ(椅子):20x2,腹筋ローラー:5x1,スクワット:20x1,縄跳び(両足跳:50x3)をした。縄跳びの疲労で日常生活で痛くなったことのない膝の後ろの、なんと呼ぶのかすらわからない筋が痛い。いまは両足跳以外の負荷のかかる跳び方はできない。

scim パーサー周りの改善

先日 実装した scim パーサー を使って scim プロトコルによる id 連携の内部処理をリファクタリングした。たまたま rfc7643 を読んでいたら go-urn の実装で食い違っているところがあって pr を送ってみた。

• Remove param from SCIM types #43

作者から教えてもらって、食い違っているのは rfc7643 の方で相反する内容が書いてある。これはこの rfc を作成した scim WG とやらにメールしてこの仕様はどちらが正なの？と聞いて訂正してもらえばいいんやろか？

加圧シャツ

トレーニングが楽しくなってきてその効率を上げようと思って加圧シャツも買ってみた。伸縮する着圧のあるシャツで体を締め付けることで血流が悪くなる。血流が悪くなると、筋繊維 (脳？) は疲労を感じやすくなり、それでより強く太い筋繊維を生成しようとする。要は脳を騙すみたいなアイテムだという。1日着ていたが、とくにお仕事や身体の動作に支障はない。上半身が締め付けられることで背筋が伸びるような気もする。よい意味で緊張感をもつことができているように思う。しばらく使ってみる。

22時からオフィスで作業していたのもあり、そのまま夜通しで作業して、6時に帰ってきて寝て9時に起きた。こんなことやっているから体調が悪くなりそうな気がする。宅急便を受け取る必要があったので午前中はのんびりしてた。なぜか宅配ボックスは毎日埋まっていてまったく使えない状態になっている。今後はコンビニ受け取りかオフィスに送るようにしよう。

ジモティー検索

以前 ジモティーで椅子を購入 してよかったので実家で使う家具でよさそうなもの、具体的にはダイニングテーブルを探している。

ジモティーとヤフオクの違いとして、ジモティーはオークションじゃないから持ち主が処分したい品物はゼロ円で譲りますと出品されていたりする。その代わり、送付はせず引き取りが必須となる。ダイニングテーブルのような大きいものだと粗大ゴミに出すにもお金がいるから持っていってくれるならそれでいいといった感覚だろうか。さらに地域に特化した引き取りを必須条件にするので誰もが応募できるわけでもない。常にみていなくてもタイミングがあえば格安で入手できる可能性がある。そこで社用車の荷室スペースのサイズを確認していた。後部座席を倒すことで荷室スペースを拡げられる。このサイズならたいていのダイニングテーブルは積載できそうに思える。

• 長さ: 680-1,480mm
• 幅: 1,000mm
• 高さ: 850mm

実家の離れオフィスのリモートワーク、さらには今後のコワーキングスペースとして使うときの家具をジモティーでのリサイクルも考慮しながら揃えていきたい。

scim 向けの urn パーサーの拡張

先日 チームのメンバーが実装した scim 連携のレビュー をした。そのときに scim の urn のパース処理を自前で実装していた。それ自体は悪くないが、urn のような標準化されたものなら専用ライブラリを使った方がよいのではないか？と思って調べてみた。予想通り作っている人はいたものの、それほど煩雑なものでもないのでライブラリを使うほどでもないのかもしれない。

• github.com/leodido/go-urn

例えば、次のような scim 向けの urn がある。

urn:ietf:params:scim:schemas:core:2.0:User

go-urn は汎用の urn パーサーなので scim に特化した属性などをパースしてくれない。それについて issue で質問してみたら、scim 向けのサブパーサー作ったらいいんじゃない？というコメントが返ってきた。そこで rfc-7643 の urn の仕様を眺めながら試しに実装してみた。この機能がマージされてもこの用途のためだけに依存ライブラリを増やすかどうかはまだ懐疑的なところ。とはいえ、せっかく調査して実装したから誰かの役に立つかもしれないと思って pr を送った。

• Add scim (rfc 7643) specific struct #33

0時に寝て2時に起きて6時半に起きた。旅行から帰ってきて睡眠の質が上がってきた気がする。

コードレビュー

週明けから毎日ずっとコードレビューをしているわけだけど、今日は scim の id 連携の実装ができたのでそのコードレビューを半日以上やっていた。変更内容は2000行弱ぐらい。以前にも scim の調査 について少し書いた。

担当者は前マイルストーンのときから調査していて、今マイルストーンで初期実装は入れてしまおうという話しを昨日の 1on1 でしていた。また qa レベルのテストは来月末ぐらいでやるので詳細を作り込むよりもまずは大きな機能として入れておきたい。いまマイルストーンの期間を2週間に設定している。調査も含めて実装まで2つのマイルストーンを費やそうとしている。理想的にはどんな機能であっても、メンバーには2週間で完了する粒度で issue を分割して作業できるようになってほしいという狙いがある。

それは過去にどんな新機能を作っていても2週間を超えることはなかったという私の経験則でもある。これは2週間でどんな機能でも完成するという意味ではなく、2週間でマージできないような区切りのつかない機能開発はないという意味だ。機能実装のような issue でマイルストーンをまたぐ開発をしていると、進捗が不透明になったり、開発がダレると私は考えている。ダレるというのは短い期間に集中して開発した方が効率も品質もよいものができるのではないか。記憶の仕組みからは理屈上そうだと言える。開発のメリハリをつけるという働き方に範を示していきたい。

22時に寝て24時に起きて4時に起きて6時に起きた。実家だとやることないので寝るのも早くなる。早く起きているので始業も7時半ぐらいになる。早起きは三文の徳。

リモートワークのタグを新設

神戸のオフィスに行かなかった日は day off というタグを付けている。名前の通り、お休みしたということを表す。この定義に従うと、実家に帰ってリモートワークをしたときもお休みになってしまうため、それを区別するように remote work というタグを作った。

scim 調査

id 連携の文脈で System for Cross-domain Identity Management (頭文字をとって SCIM、すきーむと呼ばれている) という標準がある。基本的には rest api とスキーマを扱うように仕様が決められていて、それに準拠したサービス間で id 連携を標準化する狙いがある。id 連携と同じ用途を表す用語として id プロビジョニングという用語もあるが、多くのクラウドサービスでは id プロビジョニングのために scim 対応していたりする。

たまたまサイボウズさんが okta と scim 連携に対応しているプレスリリースをみかけた。

• サイボウズの「cybozu.com」がプロビジョニング自動化実現のため、「Okta Integration Network」とのSCIM連携に対応

その延長で調査していたところ、go の scim ツールを提供していることに気付いた。しかもこれを作っているのが Maki さん。これはソースを読んでおこうと思った次第。Maki さんはメルカリに所属していたと思うのでこれは副業でやっているのかな？

• github.com/cybozu-go/scim
• github.com/cybozu-go/scim-server

scim-server は scim ライブラリを実際に使うときの参照実装としてアプリケーションの開発者に開発の雰囲気を伝えるための実装になっている。これ自体をプロダクトのサーバーとして使うわけではない。sqlite を使ってユーザー／グループの crud な操作と検索機能を提供している。

scim ライブラリのソースコードも軽くざっと読んでみた。github.com/lestrrat-go/sketch という go でスキーマを記述してコード生成する Maki さん製のツールがある。これを起点に scim のプロトコルやリソースの仕様にしたがって go のコードでスキーマを定義し、リソースに関する go のコードと scim スキーマを自動生成している。sketch というツールに関連して他にも Maki 製のメタプログラミングライブラリを多用していて、scim の標準化されている部分のエンドポイントやリソースのインターフェース部分をすべてコード生成している。

go generate やコード生成の実際の応用例として非常に参考になる。このライブラリは scim のプロトコル仕様に関する開発者と、そのエンドポイントの実際の処理 (バックエンド) の開発者を明確に分離するという開発体制を期待している。scim に関するところは Maki さんが独りでコード生成を多用してオープンなプロトコル仕様の開発を担当し、そのバックエンドをサイボウズさんの開発者が実装するという分業体制を想定しているようにみえる。

scim 対応のアプリケーション開発のプロトコル部分を外部に委譲するといった設計になっているが、scim が十分に安定していてプロトコルの仕様が変わらないのであれば理に適っているとも考えられる。バックエンドの開発者はいくらか sketch の学習コストを強いることになる。そのため、アプリケーションはその学習コストを支払ってもコード生成のメリットが上回るだけの規模や特性を要求する。おそらく scim はそれだけの価値があると判断されたのだと推測する。

私はメタプログラミングが好きな方なのでこういうやり方もあるんだなと設計の参考になった。またコード生成の要件があったときにソースを参考にしようと思う。