Posts for: #2021/12

2年目の創立記念日

0時半に寝て6時半に起きた。久しぶりに22時までお仕事やって区切りもよかったからそれからお惣菜を買って23時頃から晩ご飯を食べてた。生活が乱れるなぁ。

dapr の分散トレーシングと W3C trace context

お仕事で dapr の分散トレーシングを検証してた。知らない人は Dapr Advent Calendar 8日目 - DaprとZipkinで分散トレーシング のチュートリアルをお勧めする。dapr は W3C Trace Context を使って分散トレーシングを扱う。rest api では、具体的には traceparenttracestore という http ヘッダーにトレース用途の情報を付けて転送する。すごいところは pubsub のメッセージングを経由してもそれらの情報を転送できる。pubsub 間でこれらの情報は CloudEvents という標準化されたデータのフォーマットでやり取りされる。実際には CloudEvents の中に traceparenttracestore の値を含めて通信するけれど、外部からみたら http ヘッダーを転送できているようにみえる。しかし、http ヘッダーの任意の値を転送したい場合、それができない。tracestore はトレースのためのベンダー独自情報を付与できるとあったので、ここに任意の値をセットして送ってみたけど、http ヘッダーの付け替えは行われなかった。あとで dapr のソースを読んだら publish するときはそのまま送っているけど、subscribe するときに tracestore の仕様を満たしているか検証しながらパースしていて、任意の値を送っても仕様に沿っていなければ捨てられてしまうことがわかった。dapr の issue でも要望として登録されてた。誰もやってないならコントリビュートするチャンスかもしれない。

創立記念日

今日が会社の創立記念日。無事に2周年を迎えた。創立記念日をお休みにするしないを考えたのだけど、いま休日も普通に働いている状況で、且つ役員は勤怠管理をする必要はないので平日になんの意味もなく休むメリットが何もないということに行き着いた。創立記念日だから休むのではなく、いつでも必要なときに休めばいい。もっと言うと、休む理由がなければ働くという逆転現象が生じていて、休む理由は私用か疲労ぐらいしかなくて、基本的に疲れてない限りはずっと働くみたいな理屈になってしまっている。社員が増えて会社に余裕が出てから創立記念日は休みみたいな制度を作ればいい。それまではたぶん来年もそれ以降も普通に働いていると思う。

1年目は訳分からず働いていたから経営的なことは全くわからなかったけど、2年目は経営上の諸問題が出てきて、経営的な意思決定や考察も増えてきて、行政手続きも熟れて、会社の実績も増えていっていて、会社を育てるという意識もかなり出てきた。率直に言えば、いまの経営状態は可もなく不可もなくといったものなので何もアピールすることはない。しかし、経営したことない人間が経営というキャリアを積み重ねていることには大きな意義があって、自身のキャリアアップには確かな手応えも感じつつある。これからもがんばっていこう。

整理・整頓・清掃・清潔・躾

0時に寝て5時に起きた。今日はがんばって起きた!久しぶりに7時半から始業してた。

トヨタの5S

スクラムイベントのふりかえりをしていて トヨタの5S の話題が出た。聞いたことがあるようないような、スクラムを勉強しているいま見返すとじわじわ聞いてくる。玄人ぶって「そうそう、こういうのが大事なんだよ」とか言いたくなりそうな雰囲気がある。普通にやっていたら当たり前のことなのに、忙しかったり複雑な問題に対応してたりすると、普通の状態を維持できなくなって混沌がもたらされる気がする。そういう状況のときに初心に戻るにはこういった原則や標榜を使って啓蒙することに意義があるんだと、いまは思うようになってきた。これ自体をよいとかわるいとか言うのは適切ではなくて、うまくいっていない状態からより戻すときに活用するといった考え方の方が正しいのかもしれない。

クロスデフォルト

0時に寝て6時半に起きた。5時台には起きているんだけど、起き上がるところまではなかなかいけない。

恒大集団のデフォルト

11月から利払の期日の日はチェックしていて、支払うときは2-3日前には支払いを完了したというニュースが出ていたように思う。今日の支払いは前日に支払いしたというニュースが出ないからダメなんだろうなと様子をみていた。

1つの債務がデフォルトした場合、残りの債務も一括返済しないといけないことを クロスデフォルト と呼ぶらしい。契約書にクロスデフォルト条項として書いてあるらしい。記事によると、クロスデフォルトによって約190億ドル (約2.1兆円) のオフショア債の返済を一括でしないといけないらしい。リーマンショックのようなことは起きないという見通しだけど、うちみたいな零細企業は世の中の影響を諸に受けるのでお仕事に影響がでなければいいなぁといったところ。

アプリケーションログの調査

昨日の続き。ecs-logging-java で JSON Lines でログを制御するところで spring-boot の設定で tomcat のアクセスログの設定ができる。tomcat のアクセスログを log4j のレイアウトの仕組みを使って ecs-logging-java が提供する EcsLayout に変更できないかを3時間ほど調査して、どうもできないようだというのを教えてもらった。tomcat は apache のログを出力するという目的で実装されているから log4j の柔軟なログに対応していないという理屈。

じゃあ、どうやって apache のアクセスログを JSON Lines にするかというと、PatternLayout のパターンに json のフォーマットを直書きしてしまうというやり方がある。なんかプログラミングでスマートに解決したいところだけど、その仕組みがないなら仕方ないかって感じでこれでやろうと思う。

アプリケーションログの調査

1時に寝て7時に起きた。

アプリケーションログの調査

お仕事でログの整理をやろうとしていて、そのためのライブラリとして ecs-logging-java を調べてた。

一番のモチベーションは JSON Lines でログを管理したいというところ。この手の実装や読み込んでログ分析したりとかはあちこちでやってきたので親近感はある。既存のログからの移行も含めていろいろ設計していかないといけない。私の感覚だとアプリケーションの開発初期にログの設計や出力周りを作り込むものだけど、そうじゃない文化の開発もあるんだなという印象。あとからログ設計するとか、移行や既存のコードに手を入れたり、開発初期に作り込むより手間暇かかる気がするんだけど、そんな時間もなく開発してたってことなのかなぁ。

頭文字Dを読了

0時に寝て7時に起きてだらだらやってて午前中は 頭文字D のアニメをみてた。漫画 (アニメも?) はすでに完結しているのでいつか読もうと思いつつ最後まで読んでいない。ゴッドフットやゴッドアームが出てくるぐらいまでは読んだ気がする。その後どうなったのかを知らない。イニシャルDをみていると、ストーリーも絵も演出もまったく派手さはなくて普通なんだけど、なぜかおもしろくて続きをみてしまうという人間の娯楽の本質をついている気がしてくる。なんでなんだろうなぁ。

頭文字D

たまたま思い出したので夜に漫画喫茶行って頭文字Dを最後まで読んできた。全48巻で、31巻ぐらいから読み始めて3-4時間ぐらいで読み終えた。漫画なので仕方ないけど、対戦相手がどんどん強くなっていって勝ち方が玄人好みというのか、単純に抜いた・抜かれたの話しではなく、タイヤマネージメントがどうこうとか、恐怖に対する心理がどうこうとか、ドライバーと車のセッティングも含めた駆け引きが強くなっていって、どちらが速いかというよりは戦略通りの展開にもっていって最後はそれがうまくはまるみたいな、これまでもずっとそうだったんだけど、ここからはよりトップレベルのほんの僅かな差が勝敗を分けるといった描き方になっていったように思う。それはそれで現実に近い気はするけど、漫画的には派手な演出にならないので玄人好みなストーリーになっていった気がする。但し、そこまでやってきて最後の対戦相手だけは、個人的には納得感がなくて、ここまで緻密に作り上げてきた理論や個々のドライバーの修練の積み重ねが圧倒的天才の前にひれ伏すみたいな切り口が急展開していて、頭の切り替えができなかった感じがした。とはいえ、最後まで読み終えられてよかったし、作品としてはすごくおもしろかった。作者はモータースポーツが本当に好きなんだろうなというのが伝わってくる漫画だと思う。

ふるさと納税

あまり欲しいものもないし、ふるさと納税の行政手続きも一通り理解したから今年はやらなくてもいいかとも思っていた。しかし、paypayボーナスキャンペーン をみてやってみるかという気になった。paypay はいろんなものと連携していて見かけるたびにすごいなと思う。お得だからと必要もないものを買うことはないけど、ふるさと納税はやらなかったとしても、どのみち納税は必要なものなので還元があるということは節税につながるのかな?理屈はよくわからないけど、言いたいことは paypay はすごいという話でした。

dapr の api トークンを使った認証

Enable API token authentication in Dapr を一通り読んだ。内容はとくに難しくなく、こんな風に dapr の manifest を書けば JWT トークンを設定できますということを書いてある。私はずっとサーバーサイドばっかりやってきたからフロントエンドで使われる技術や仕組みに弱い。JWT トークンもその1つで、自分でちゃんと実装したことがないからちゃんとよく分かってない。これが OAuth2 なら provider を実装したこともあるからその仕組みも意図も理解できる。一度どこかで自分で JWT も実装してみないといけないのだろうな。

少し前にお仕事で kubernetes の secret の移行作業をやった。既存の secret にキーバリューを追加するときは patch を使う。

$ kubectl patch secret mydata -p='{"stringData":{"mykey": "myvalue"}}'

secret の内容を確認するときも2つのやり方がある。キーだけを確認するならこれでよい。

$ kubectl describe secrets mydata

キーに対応する値もデコードして確認するならこうする。但し、閲覧注意。

$ kubectl get secret mydata -o json | jq '.data | map_values(@base64d)'

github actions のビルドキャッシュ運用

23時に寝て5時に起きてちょっと作業してまた寝て7時に起きた。お仕事も働き始めて1ヶ月が経過して、だいぶチームの雰囲気や業務に慣れてきたところ。稼働日の18日間で作成した pr が16件。入ったときに割当てられた3つの課題から10数件の issue を派生させてちょうどすべて fix した。来週から新しい課題に取り組む。

ストレッチ

今週もお仕事に注力してたらストレッチは2日/週とあまりできなかった。ウォーキングもやってない。今日の開脚幅は開始前165cmで、ストレッチ後167cmだった。さぼってたせいか、数値が悪くなってしまった。右股関節の関節の可動域がよくないところは少しずつまがるようになってきてよくなってきている実感がある。一方で右太ももの後ろの筋が張りが大きいことに気付いた。トレーナーさんに聞くと、この筋は椅子に座っていると張りやすいという話しなので、最近はお仕事に注力して椅子に座っている時間が以前より伸びているせいだと思う。あと会議に出席している時間も増えているため、その時間は椅子に座っておかないといけないという制約も増えている。

actions/cache の exclude 設定

github actions でビルドキャッシュを扱う方法は Caching dependencies to speed up workflows に書いてあって、それは actions/cache という github actions がキャッシュ機能を提供している。ここでドキュメントにはキャッシュの除外設定については何も書かれていないが、リポジトリに含まれる examples.md には次のような説明と設定例が出てくる。

Depending on the environment, huge packages might be pre-installed in the global cache folder. With actions/cache@v2 you can now exclude unwanted packages with exclude pattern

https://github.com/actions/cache/blob/main/examples.md#c---nuget

- uses: actions/cache@v2
  with:
    path: |
      ~/.nuget/packages
      !~/.nuget/packages/unwanted      
    key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
    restore-keys: |
      ${{ runner.os }}-nuget-      

! を入れるだけかと思って検証してみたらどうも意図した振る舞いにならない。実はこの設定はバグっていて実際には動かない。なぜ動かないかを追いかけてないけど、issue にも登録されている。path の記述方法によって動いたり動かなかったりするというのが現状の振る舞いになるらしい。

ちなみに正しい動く設定は次になる。ワイルドカードを使わないといけないらしい。ドキュメントに除外設定について書いていないのはバグってて中途半端な振る舞いをしているからかもしれない。

- uses: actions/cache@v2
  with:
    path: |
      ~/.nuget/packages/*
      !~/.nuget/packages/unwanted      
    key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
    restore-keys: |
      ${{ runner.os }}-nuget-      

あとビルドキャッシュのキーにパッケージ管理のファイルのハッシュ値を取るようになっている。この背景も github actions がキャッシュをクリアする機能を提供していないからであろう。Clear cache #2 でも議論されているが、キャッシュをクリアできないため、同じキーにパッケージが溜まり続けるような運用は開発者にとっても github 社にとってもリソースを浪費するので好ましくない。いまは7日以上アクセスされていないキャッシュを削除する運用になっているため、なるべくフレッシュなキャッシュが生成されるような運用となるよう、ハッシュ値を取得するようなキーの運用が行われているように推測される。

チームごっこ

0時に寝て6時に起きた。

朝活: アジャイル開発とスクラム 第2版

第7章の残りと第8章を読んだ。事例紹介なので軽く読み流した感じ。インタビュー記事のタイトルが気になった。

「合宿で、「仕事での同僚」から「チームの仲間」になれました

このタイトルと内容に私は違和感があるので反論としてそれを書いていく。

心理的安全性のつくりかた に書いてあったが、MIT のオスターマン教授によると、チームという概念は比較的新しいものらしい。

職場における、チームという概念は1980年以降、最も広まったイノベーションのひとつだ。

「心理的安全性のつくりかた」ではチームとグループの違いは次になる。

  • チームは共通の目標に向かってともに問題解決やアイディアを出す集団
  • グループはそうなっていない、ただの寄せ集めの集団

共通の目標に対して互いに対話や協働することでチームになっていく。この考え方は私の経験則とも合致するし支持している。実際の業務や作業を通してチームは築かれていくと私は考える。しかし、コミュニケーションの活性化や親睦を深めればチームになると誤解している人もいるように思う。

件のインタビュー記事では、次の内容があった。

合宿の最大の成果は、何だったのでしょう?

「仕事での同僚」から「チームの仲間」になれたことだと思います。昨今、ハラスメントやプライバシーの観点からなかなか個人の深い話ができないことが多いと思いますが、お互いを信頼した上で自分の生い立ちや経験から「私がなぜここにいるのか」を深掘りできたことが大きいと思います。

具体的には、誰とも話さず、自分を見つめる時間として三浦海岸の浜辺に全員を1時間放置しました(笑)。その時間で自分の今までをふりかえり、再集合したときに1人ずつ語り、お互いのことを尊重し受け入れることで心理的安全性が一気に高まったと思います。

私だったら転職を考えますね。浜辺に放置されて再集合して生い立ちとか語れとか言われて、そんな上司だと懸念を抱くと思う。その場で抗議はしなかったとしても。仕事を通して結果的に信頼関係が深くなって、同じ行動をするなら理解できるが、そうじゃない状態で職位の高い人がメンバーに合宿を半強制参加させてプライベートの内容を話させるのはハラスメントと紙一重かもしれない。おそらくこれはたまたまうまくいったケースだというだけで再現性のあるプラクティスにはまったく思えない。厳しい言い方をすると、偉い人の自己満足によるチームごっこではないかと思う。

本番リリース作業

今日は非稼働日なんだけど、インフラ周りの修正をしていたので本番リリースの作業を見守っていた。ハドルで画面共有しながらみんなでわいわいできるので、これはこれでリリース作業の雰囲気を学ぶ機会にもなる。私が本番リリースすることはないだろうけど、担当者がどういった作業でリリースしているかを知っておく方が運用に役に立つ仕組みも導入できるかもしれない。音声通話と画面共有さえあればフルリモートワークでもなにも困ることはない。よい世の中になったと思う。RabbitMQ と Dapr 周りで私が懸念に思っていたことを本番リリースを通して検証したり振る舞いを観察できたので新たな知見を得た。

スクラムイベントにもの思い

23時に寝て6時半に起きた。昨日は疲労困憊だったのでなんもせずすぐ寝た。

スクラムイベント

お仕事のスクラム開発で木曜日はスプリントレビューとプロダクトバックログリファインメントを行う。主にステークホルダーとプロジェクトオーナーがプロダクトバックログアイテムの優先度を議論したり、タスクに細分化されていない課題をタスクにしていくための作業に当てたりしている。本当はタスク化されたイシューをさらにリファイメントするイベントなのだろうだけど、まだそこまで業務やチームの体制が成熟していないため、タスクの細分化のための時間になっていたりしている。

これらのイベントで開発者がイニシアティブをとることはないけど、プロダクトオーナーやその業務チームにいるメンバーたちがどうやって業務をタスク化しているかのやり取りもみえたりする。開発者にとってそのやり取りをみていることに意味があるかどうかはまだ私にはわからないが、業務チームのメンバーがどういった働き方をしているかを知るきっかけにはなる。業務チームは miro を使ってメンバーみんなで同時編集しながら課題を付箋代わりのメモに落としていく。その個々のメモがタスクに近いものになるのだろうけど、私からみたら業務すべてを知っている人がまとめて細分化してドキュメントに書き記して2-3回みんなでレビューすれば終わるようなものを、みんなで付箋紙に書いていって整合性が取れているのかどうかわからないメモの固まりを作っているようにみえる。この作業はみんなでやらないと進捗しないので1週間に1回とかになる。

  • チームが扱うすべての業務を知っているメンバーはいない
  • 業務に必要な機能の優先順位や優先度を決める権限をもっていない
  • 情報が足りないと思ったときにメンバーが自律的に動いて補う体制が整っていない

あとステークホルダーが話す要件や仕様に関わってくる話の大半が口頭で行われていてドキュメントや課題管理に文章として書き記されていない。だから同じ話しを何度も繰り返し聞くようなケースも発生する。わからないことを聞くことも、繰り返し聞くことも問題ではないが、議事録以外にそこで話す内容がドキュメント化されないのはどうしてだろう?という気もした。もっともっと文章を書かないと情報共有やノウハウをためることにはつながっていかないだろうということも垣間みえる。

総括すれば、どんな開発方法論を使っても、リーダーやマネージャークラスが圧倒的に文章を書けないと、その配下のメンバーは自律的に行動できないというだけの話しでしかないが、どうやったら解消できるか?はまだまだこれからの私の課題でもある。

師走入り

1時から1時間ほど仮眠をとって2時から4時過ぎまで作業して帰ってお風呂に入ってそのまま6時から 【三宮.dev オンライン】リモート朝活もくもく会 の朝活に参加した。30分ほど雑談して眠くなって7時過ぎから9時前まで寝てた。

dapr の pubsub の dead letter サポート

お仕事で dapr を触っている。pubsub で dead letter queue の仕組みを導入しようとしているが、PubSub’s DeadLetter Topic #2217 によると v1.6 (2022年1月20日リリース予定) のマイルストーンになっている。本当にその予定ならそろそろベータ版が実装されていて、開発ブランチあったらテストしようかと考えていた。調べてたら rabbitmq はすでに v1.5 で dead letter のサポートがマージされているのを発見した。

たまたま、いま使っている pubsub も rabbitmq だった。ドキュメントをみたら確かにその設定が追加されている。

dapr RabbitMQ

FieldRequiredDetailsExample
enableDeadLetterNEnable forwarding Messages that cannot be handled to a dead-letter topic. Defaults to “false”“true”, “false”
maxLenNThe maximum number of messages of a queue and its dead letter queue (if dead letter enabled). If both maxLen and maxLenBytes are set then both will apply; whichever limit is hit first will be enforced. Defaults to no limit.“1000”
maxLenBytesNMaximum length in bytes of a queue and its dead letter queue (if dead letter enabled). If both maxLen and maxLenBytes are set then both will apply; whichever limit is hit first will be enforced. Defaults to no limit.“1048576”

enableDeadLetter=true に設定して、適当にエラーが発生しそうなリクエストを作って dead letter にメッセージが入るかどうかを検証してた。ひとまず dead letter にメッセージが入ること自体は確認できた。

bizpy 勉強会

Python で Slack のインテグレーションをやってみる勉強会 #3 を開催した。月曜日から2時間もあればできる資料作成をだらだら先送りしていて夜中に作った。なんか体調を崩しているのかもしれない。たまたま勉強会の前にせらさんから激励のコメントをいただいて嬉しかった。

今日の分も含めコンテンツ拝見しましたが、素晴らしいですね

私見だけど、slack インテグレーションで調べものをしているとせらさんの記事や issue のやり取りをみかけることが多い。twitter で slack インテグレーションに関してつぶやくと100%せらさんからレスポンスがある (個人の経験談) 。過去に私は外資の ISV で働きたいと思って活動したこともあったけど、せらさんをみていて自分のレベルでは無理だったなと得心がいった。なにがすごいって、bizpy の勉強会のようなところにもわざわざやってきて、講師にコメントしたりアドバイスしてくれるんだからね。

2ヶ月に渡り、slack インテグレーションのチュートリアルレベルの記事を実際に設定してみて、サンプルコード書いてみて、動かしてみて、slack でどんなことができそうかの理解を深めることができた。今回の内容はビジネスパーソン向けではなかったのでちょっと敷居が高かったかもしれないが、全3回でやり切ることができてよかった。終わってから運営に新たにわたなべさんが加わったことを参加者に紹介しつつ、次回の企画について雑談していた。次回はわたなべさんから機械学習入門のような勉強会をしてもらうことに決まった。